Conversation
561c93e to
66db29c
Compare
| if ((envOptions = strdup(argv[j+1])) == NULL); | ||
| { | ||
| fprintf(stderr, "ddxProcessArgument: WARNING! failed string allocation.\n"); | ||
| FatalError("malloc failed"); |
There was a problem hiding this comment.
Wouldn't it be good to mention what we tried to malloc here?
There was a problem hiding this comment.
Well, maybe. But if you happen to suffer from malloc failing you have other problems... ;-) Will extend these messages anyway.
| if ((envOptions = strdup(envDisplay)) == NULL); | ||
| { | ||
| envOptions = strcpy(envOptions, envDisplay); | ||
| FatalError("malloc failed"); |
| if (nxagentOptionsFilename == NULL) | ||
| { | ||
| fprintf(stderr, "ddxProcessArgument: WARNING! failed string allocation.\n"); | ||
| FatalError("malloc failed"); |
| return 2; | ||
| } else { | ||
| FatalError("malloc failed"); | ||
| FatalError("malloc failed"); |
| nxagentKeyboard = NULL; | ||
| } | ||
|
|
||
| /* FIXME: why limit to 256? */ |
There was a problem hiding this comment.
Probably some comand line length limitation adopted here?
| sleep_parse = strtol(value, NULL, 10); | ||
|
|
||
| if ((errno) && (0 == sleep_parse)) | ||
| if ((errno) && (sleep_parse == 0)) |
There was a problem hiding this comment.
@Ionic: I noticed these comparisons, too, when you worked on the sleep and tolerance feature. Any reason for having the order == ?
There was a problem hiding this comment.
I think this is a coding habit that prevents accidently writing = instead of ==. The compiler will complain if you try to assign a value to a constant.
There was a problem hiding this comment.
Yes, exactly for this reason. It's a pretty common pattern to avoid mistakes (and I'd like to keep that part.)
| if ((size = strlen(argv[i])) < 1024) | ||
| { | ||
| if ((nxagentOptionsFilename = strndup(argv[i], size)) == NULL; | ||
| if ((nxagentOptionsFilename = strndup(argv[i], size)) == NULL); |
There was a problem hiding this comment.
the semicolon at the line end feels wrong. Also: please rebase with the previous commit that you try to fix with this commit.
|
I also noticed I still have some fixup commits in there. New version to come soon ;-) |
836225d to
320f413
Compare
|
Ready for another round. I have added some more changes, so please start over again. |
320f413 to
5d022f7
Compare
|
rebased |
| /* | ||
| * This is the entry point, called from os/utils.c | ||
| */ | ||
|
|
There was a problem hiding this comment.
I'd drop the newline here and in the next hunk.
|
|
||
| if (nxagentOptionsFilenameOrString != NULL) | ||
| free(nxagentOptionsFilenameOrString); | ||
| if ((nxagentOptionsFilenameOrString = strdup(argv[j + 1])) == NULL) |
There was a problem hiding this comment.
That's more compact, but potentially also slower. We probably don't really care since this code will be only called "once". (Actually multiple times, but only once during the program's lifetime.) Just mentioning it.
There was a problem hiding this comment.
Speed was not an issue here. I just wanted to simplify the code to make it more readable.
| for (j = 0; j < argc; j++) | ||
| { | ||
| /* | ||
| * Read the _last_ options file only and only at startup. |
There was a problem hiding this comment.
This breaks compatibility. Previously, only the first options file was used, now it's the last one. Is that a good idea? At least it would make nxagent more compatible with other tools, since most programs allow users to override values for previous parameters by specifying them again with only the last one taking effect.
To be precise: it may look like it's compatible to the previous behavior, but it isn't. Previously, the code scanned for -option(s) and took the first match, then parsed it as an options file. Afterwards, subsequent uses of ddxProcessArgument() overrode the internal nxagentOptionFile (or nowadays nxagentOptionsFilenameOrString) variable. That's an important difference because it allows for a very special combination:
- start up nxagent with a special options file (first
-option(s)argument) - override it again via subsequent
-option(s)arguments, which will only change the internal data, but NOT lead to immediate parsing - on reconnects ONLY parse the newly registered options file
With your changes, that would not be possible.
I wonder if that behavior is a bug or a feature (i.e., whether this was intended or just an unintentional feature).
There was a problem hiding this comment.
making it behave like most other tools was the intention of my change.
You are also right about changing the options file name for reconnect (only). But consider this an unintended behaviour. The whole options parsing code is very ugly anyway... Besides: that is not documented anywhere, AFAIKS.
|
|
||
| nxagentDisplayName[1023] = '\0'; | ||
|
|
||
| strncpy(nxagentDisplayName, argv[i], sizeof(nxagentDisplayName) - 1); |
There was a problem hiding this comment.
Will cause hard to debug problems if we ever decide to change nxagentDisplayName to a pure pointer instead of an array. The alternatives are either hardcoding a value (like previously), or using a length macro. Both aren't very nice, but I guess the latter is the safest and best-looking route.
There was a problem hiding this comment.
(changing those array to pointers is on my list already)
Well, if we change nxagentDisplayName to be a pointer using a hardcoded value will also be wrong. So the situation does not get worse with my change. It only makes it easier to change that hardcoded value because it is now at only one location.
Besides, all this nullbyte stuffing will be gone once we are using pointers. We can even get rid of it now by using s(n)printf() instead of str(n)cpy().
There was a problem hiding this comment.
Well, if we change nxagentDisplayName to be a pointer using a hardcoded value will also be wrong. So the situation does not get worse with my change. It only makes it easier to change that hardcoded value because it is now at only one location.
Yes, that's why I recommend using a macro defining each length, e.g., NXAGENTDISPLAYNAME_LENGTH = ... in the header file and using that throughout the code instead of a hardcoded value.
Even if we change the variables to pure pointers, the situation wouldn't really change. We probably should bound the data length with pure pointers as well. Otherwise, str(n)cpy will crash on invalid input data. With bounding, we will in the worst case get LEN-1 bytes of garbage data, but no actual crashes.
sizeof(ptr) doesn't work for pure pointers, so we'd have to change these sections again anyway.
I agree that dropping the hardcoded numbers is a good idea, but IMHO the best way (also taking into account further changes to pure pointers) is to use macros instead.
|
|
||
| *(nxagentSessionId + 255) = '\0'; | ||
|
|
||
| strncpy(nxagentSessionId, argv[i], sizeof(nxagentSessionId) - 1); |
| if (i + 1 < argc) | ||
| { | ||
| if (NULL != (nxagentKeystrokeFile = strdup(argv[i + 1]))) | ||
| if ((nxagentKeystrokeFile = strdup(argv[i + 1])) == NULL) |
There was a problem hiding this comment.
I fully get you point here, but I want to keep the code uniform within a file. And the rest of the code has the constant at the right side. The Xorg code is also using this technique.
There was a problem hiding this comment.
Welll... okay.
Personally, I'll be keeping this style for new submissions, particularly since it's just a cosmetic issue and provides a potential benefit.
I totally respect your decision, though. It's fine.
| tolerance_parse = strtol(value, NULL, 10); | ||
|
|
||
| if ((errno) && (0 == tolerance_parse)) | ||
| if ((errno) && (tolerance_parse == 0)) |
| strncpy(nxagentWindowName, "NX", 255); | ||
|
|
||
| *(nxagentWindowName + 255) = '\0'; | ||
| strncpy(nxagentWindowName, "NX", sizeof(nxagentWindowName) - 1); |
There was a problem hiding this comment.
Same issue here as some hunks above.
| strcpy(nxagentDialogName, "NX"); | ||
|
|
||
| *(nxagentDialogName + 255) = '\0'; | ||
| nxagentDialogName[sizeof(nxagentDialogName) - 1] = '\0'; |
There was a problem hiding this comment.
Same problem as some hunks above.
| { | ||
| strncat(nxagentDialogName, nxagentSessionId, length - (MD5_LENGTH * 2 + 1)); | ||
| strncat(nxagentDialogName, nxagentSessionId, | ||
| MIN(length, sizeof(nxagentDialogName) - 1 - strlen(prefix))); |
There was a problem hiding this comment.
Same problem as above.
Bounding the size is actually a pretty good idea here, though.
|
Took me a while go through all of this, sorry... |
a973993 to
39fe99d
Compare
|
pushed updated version |
|
|
||
| nxagentDisplayName[1023] = '\0'; | ||
|
|
||
| strncpy(nxagentDisplayName, argv[i], sizeof(nxagentDisplayName) - 1); |
There was a problem hiding this comment.
Well, if we change nxagentDisplayName to be a pointer using a hardcoded value will also be wrong. So the situation does not get worse with my change. It only makes it easier to change that hardcoded value because it is now at only one location.
Yes, that's why I recommend using a macro defining each length, e.g., NXAGENTDISPLAYNAME_LENGTH = ... in the header file and using that throughout the code instead of a hardcoded value.
Even if we change the variables to pure pointers, the situation wouldn't really change. We probably should bound the data length with pure pointers as well. Otherwise, str(n)cpy will crash on invalid input data. With bounding, we will in the worst case get LEN-1 bytes of garbage data, but no actual crashes.
sizeof(ptr) doesn't work for pure pointers, so we'd have to change these sections again anyway.
I agree that dropping the hardcoded numbers is a good idea, but IMHO the best way (also taking into account further changes to pure pointers) is to use macros instead.
| if (i + 1 < argc) | ||
| { | ||
| if (NULL != (nxagentKeystrokeFile = strdup(argv[i + 1]))) | ||
| if ((nxagentKeystrokeFile = strdup(argv[i + 1])) == NULL) |
There was a problem hiding this comment.
Welll... okay.
Personally, I'll be keeping this style for new submissions, particularly since it's just a cosmetic issue and provides a potential benefit.
I totally respect your decision, though. It's fine.
ee8d03d to
f5346e4
Compare
f5346e4 to
d11ebd1
Compare
Warnings that are guarded by ifdefs are for the users. Therefore they must not contain the function name. Also some of the messages had not been prefixed by "Warning".
we already know the exact value of the name variable so there's no need to validate it.
Within Args.c values in messages are not enclosed by [] but ''. The [] format is only used for debugging/testing messages.
Use strndup instead of malloc + strncpy. Don't issue just a warning if that fails but issue a FatalError.
We use (variable == constant) everywhere.
An options string/filename can only be provided via the command line or environment. Both are handled in the one-time init part of ddxProcessArguments() and will not change during runtime. As we do not want an options file to include another "options" option there's no need to handle that a second time. Due to the (kind of crazy) way nxagent handles all this option stuff we cannot remove the second check completely. This also removes the 1024 byte limit for nxagentOptionsFilenameOrString.
Could not find a reason to limit that string.
d11ebd1 to
19126af
Compare
|
rebased |
|
No, this is a different topic
Mike Gabriel <notifications@github.com> schrieb am Fr., 24. Aug. 2018,
13:41:
… @uli42 <https://github.com/uli42>: Is this PR outdate now with #725
<#725> merged?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#557 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGBw5H3w2dVMCfxdMoQqiFI5tfmf7JERks5uT-ZfgaJpZM4QjN-K>
.
|
some improvements for
Args.c