duplicate handling of lsbcc -include argument - problem?
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
lsb |
In Progress
|
Medium
|
Unassigned | ||
Mandriva |
In Progress
|
Medium
|
Bug Description
This may not break anything, but it seems worth recording. During visual
inspection of lsbcc.c, looking for something different we see this in the arg
handling. First in the long_options:
struct option long_options[] = {
...
#define COPY_ARG_START 100
#define COPY_ARG_END 201
/*
* The options with numbers between 100 and 200 are of special kind.
* They expect another argument right after them. Therefore, after
* option processing, this argument should remain succeeding these
* options. However, such options may be encountere in other places
* (for example, in short-options-
* Here's the full list of them (gcc 4.3.3 man):
...
-include file
...
*/
...
The arguments at the beginning of the long_options array, the ones with
option.val=0, get some special processing anyway, and the case with
option.val=105 is handled in the chunk that does COPY_ARG_START to COPY_ARG_END
so I can't tell at the moment whether there's real duplication here or not.
[reply] [-] Comment 1
Changed in mandriva: | |
importance: | Unknown → Medium |
status: | Unknown → In Progress |
tags: | added: lsbcc zclose |