View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000177 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2009-11-03 22:32 | 2013-04-16 13:06 |
Reporter | Don Cragun | Assigned To | ajosey | ||
Priority | normal | Severity | Editorial | Type | Error |
Status | Closed | Resolution | Accepted As Marked | ||
Name | Don Cragun | ||||
Organization | N/A | ||||
User Reference | strtok() example | ||||
Section | strtok() | ||||
Page Number | 2041 | ||||
Line Number | 64700-64701 | ||||
Interp Status | --- | ||||
Final Accepted Text | 0000177:0000293 | ||||
Summary | 0000177: mismatch between example description and code | ||||
Description | P2041, L64688-64689 says that the code presented below looks for combinations of <space>, <tab>, or <new-line> characters, but the code on L64700-64701 doesn't include <tab>. | ||||
Desired Action | Change: key = strtok(line, " \n"); data = strtok(NULL, " \n"); on P2041, L64700 to: key = strtok(line, " \t\n"); data = strtok(NULL, " \t\n"); | ||||
Tags | tc1-2008 |
|
We should fix the LINE_MAX problem in the example at the same time. Changing LINE_MAX to LINE_MAX+1 on line 64697 would work, but would still give the impression that it's okay to use static arrays to hold lines. (In general it isn't okay, because LINE_MAX is "runtime increasable" - the macro value in <limits.h> might be smaller than the true {LINE_MAX} limit.) A simple fix would be to avoid the problem by changing char line[LINE_MAX]; char *key, *data; to char *line, *key, *data; Also the struct element declared at lines 64692-5 is not used and should be deleted. |
|
dynamic allocation example of fgets(), per discussion: #include <limits.h> #include <unistd.h> #include <stdlib.h> #include <stdio.h> int f(FILE *fp) { long line_max; /* used to avoid multiple sysconf() calls */ char *line; /* the buffer */ /* declare other variables function needs */ /* get implementation instance's max expectable line length */ line_max = sysconf(_SC_LINE_MAX); /* account as practical for fgets() appending a NULL char */ if (line_max = LONG_MAX) return EOVERFLOW; line_max ++; line = malloc(line_max); /* get the buffer space */ if (line=NULL) return ENOMEM; /* error check required by malloc() */ /* set up other declared variables needed for the loop's processing */ while (fgets(line, line_max, fp) != NULL) { /* process returned full or partial line, accounting for there may be embedded NULL chars along with the appended one; assumes fgets result = line when non-NULL */ }; /* process possible fgets error values returned in errno and handle normal EOF condition */ free(line); /* clean up the dynamic memory usage */ return 0; /* function succeded */ } |
|
Based on other discussions concerning the use of LINE_MAX in the standard, I now propose changing the entire example instead of just the two line I suggested when I submitted this report... Change the second strtok() example on P2041, L64687-64702 from: <bold>Breaking a Lina</bold>e The following example uses strtok() to break a line into two character strings separated by any combination of <space>, <tab>, or <newline> characters. #include <string.h> ... struct element { char *key; char *data; }; ... char line[LINE_MAX]; char *key, *data; ... key = strtok(line, " \n"); data = strtok(NULL, " \n"); ... to: <bold>Find first two fields in a buffer</bold> The following example uses strtok() to find two character strings (a key and data associated with that key) separated by any combination of <space>, <tab>, or <newline> characters at the start of the array of characters pointed to by buffer. #include <string.h> ... char *buffer; ... struct element { char *key; char *data; } e; ... // Load tbe buffer... ... // Get the key and its data... e.key = strtok(buffer, " \t\n"); e.data = strtok(NULL, " \t\n"); // Process the rest of the contents of the buffer... ... |
|
How about having the example use strtok_r() instead of strtok()? Not particularly relevant to the point of the code, but the more developers are encouraged to use strtok_r() over strtok(), the better. |
|
Honestly, I think that making LINE_MAX (and similar values) a run-time increasable value is just not worth it. It turns these simple examples into non-trivial exercises, obscuring the point these examples intend to make. The same holds for applications that wish to conform to POSIX: they are bogged down trying to fulfill all these requirements, with little gain for the user. If vendors wish to add this feature to their systems, fine. However, requiring applications to cope with all this stuff decreases the viability of POSIX, in my view. EDIT: I now understand that the requirement to deal with POSIX-specified text files (newline terminated lines no longer than {LINE_MAX}) does not apply to applications, only to utilities specified to read text files. In consequence, run-time increasable values are a quality-of-implementation issue and pertain to the implementation only. Thus, the above objection is moot. |
Date Modified | Username | Field | Change |
---|---|---|---|
2009-11-03 22:32 | Don Cragun | New Issue | |
2009-11-03 22:32 | Don Cragun | Status | New => Under Review |
2009-11-03 22:32 | Don Cragun | Assigned To | => ajosey |
2009-11-03 22:32 | Don Cragun | Name | => Don Cragun |
2009-11-03 22:32 | Don Cragun | Organization | => N/A |
2009-11-03 22:32 | Don Cragun | User Reference | => strtok() example |
2009-11-03 22:32 | Don Cragun | Section | => strtok() |
2009-11-03 22:32 | Don Cragun | Page Number | => 2041 |
2009-11-03 22:32 | Don Cragun | Line Number | => 64700-64701 |
2009-11-03 22:32 | Don Cragun | Interp Status | => --- |
2009-11-04 09:54 | geoffclare | Note Added: 0000277 | |
2009-11-05 21:43 | SHwareSystems | Note Added: 0000286 | |
2009-11-10 20:21 | Don Cragun | Note Added: 0000293 | |
2009-11-10 20:42 | tahonermann | Note Added: 0000294 | |
2009-11-11 09:09 | Konrad_Schwarz | Note Added: 0000295 | |
2009-11-12 16:41 | msbrown | Final Accepted Text | => 0000177:0000293 |
2009-11-12 16:41 | msbrown | Status | Under Review => Resolved |
2009-11-12 16:41 | msbrown | Resolution | Open => Accepted As Marked |
2009-11-16 07:47 | Konrad_Schwarz | Note Edited: 0000295 | |
2010-09-09 15:28 | Don Cragun | Tag Attached: tc1-2008 | |
2013-04-16 13:06 | ajosey | Status | Resolved => Closed |