C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  function pointer Goto page Previous  1, 2, 3 ... 8, 9, 10, 11, 12, 13  Next          C++Talk.NET Forum Index -> C Language (Moderated) View previous topic :: View next topic   Author Message James Dennett Guest Posted: Fri Sep 01, 2006 12:18 am    Post subject: Re: meaning of strcat(p,p) -- was: managed string library kuyper (AT) wizard (DOT) net wrote: Quote: James Dennett wrote: Jonathan Leffler wrote: websnarf (AT) gmail (DOT) com wrote: [...] (so strcat(p,p) leads to UB even though it has a compelling intuitive meaning). What's the compelling intuitive meaning? To me, it means copy characters from the start of p over the null that used to mark the end of p and keep going until you crash. The simpler expectation from the interface is "append a copy of the string *currently* pointed to by p to p", i.e., append it to itself. Other languages that support this via notation such as s+=s; or s = s+s implement it this way. If you think of strcat in terms of its implementation or, in terms of it's specification by the standard, But the point was to think of the *intuitive* meaning of strcat, not its formally specified meaning. The standard doesn't capture the intuitive (or, if you prefer, naive) expectation. Which is fine by me, as I don't expect that intuition will be sufficient for robust programming. -- James -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Douglas A. Gwyn Guest Posted: Fri Sep 01, 2006 12:18 am    Post subject: Re: malloc help "Kenneth Brody" <kenbrody (AT) spamcop (DOT) net> wrote in message news:clcm-20060825-0017 (AT) plethora (DOT) net... Quote: Just curious -- was C89 the first "standard"? It was the first one recognized as a standard for programming language C by numerous national standards organizations. Quote: The reason I ask is that I know of at least two C compilers (from the early 1980's) that would have crashed on "free(NULL)". Many earlier implementations would indeed have malfunctioned when free was invoked with a null pointer. Note also (as a separate matter) that before the 1989 C standard, there were no prototypes nor automatic conversion to and from void*, so invoking "free(NULL)" would also be wrong from a type- correctness point of view (NULL expanding to plain 0 in most implementations). Quote: I don't have my K&R accessible at the moment to look it up. Were these systems "broken", or was there no requirement about this, way back then? K&R 1st Ed. didn't provide detailed specifications for library functions. Most "specs" for free at the time of the 1989 standard said that the argument must be a pointer value previously returned by malloc, realloc, or calloc. Whether that would include a null pointer value was not clear. Some "specs" noted that providing a "random" argument would cause unpredictable results. -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Douglas A. Gwyn Guest Posted: Fri Sep 01, 2006 12:18 am    Post subject: Re: managed string library "Robert Seacord" <rcs (AT) sei (DOT) cmu.edu> wrote in message news:clcm-20060825-0014 (AT) plethora (DOT) net... Quote: was an intentional decision on our part, as in-line usage typically prevents/discourages a user from checking the return status of the function. My point of view is that requiring the programmer to explicitly test for correctness is not appreciably better than the current situation, and that usage errors (as opposed to expected "failures" such as testing for the existence of a file by name) are best handled by throwing an exception, so that *some* strategy for handling such errors is *always* in place. With nested exception handlers, this strategy can be established at the lowest feasible level for an intelligent recovery procedure, or allowed to default to a higher- level strategy that provides a "coarser grained" recovery. The programmer still retains total control (if he wants to exert it), but the exceptional-case handling does not clutter the main-line logic. And yes, nested exception handling is certainly possible in Standard C; there have been several implementations. -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Brian Inglis Guest Posted: Fri Sep 01, 2006 12:18 am    Post subject: Re: tolower macro On 18 Aug 2006 08:49:33 GMT in comp.lang.c.moderated, Keith Thompson <kst-u (AT) mib (DOT) org> wrote: Quote: "Herbert Rosenau" <os2guy@pc-rosenau.de> writes: On Wed, 9 Aug 2006 16:51:39 UTC, jgd (AT) cix (DOT) co.uk (John Dallman) wrote: In article <clcm-20060725-0014 (AT) plethora (DOT) net>, doskix (AT) gmail (DOT) com () wrote: I was looking at <CTYPES.H> after chatting with some friends about binary math. What I saw, and researched a little is that historically, tolower is a macro defined like this. #define _tolower(_c) ((_c)-'A'+'a') That definition works with both ASCII and EBCIDC character codes, and any sensible compiler will compound the two operations into a single addition. No, that _tolower() macro is *not* a valid implementation of tolower(). Check it! What is the result of _tolower('a') _tolower('z') _tolower('ß') _tolower('ä') _tolower('?') -tolower('3') None of them will give back the same value as enterd as parameter. Right, because _tolower and tolower are two different things. On EBCDIC lower letters are not in any postion in equal difference. Actually, they are. Unlike ASCII, the EBCDIC uppercase letters are not contiguous, nor are the EBCDIC lowercase letters. But the gaps are in the same places, and it happens that the _tolower() macro above would work as well for EBCDIC as it does for ASCII. EBCDIC-US only! What about the accented EBCDIC letters? What about letters without any equivalent in the other case? Quote: In any case, the standard(s) (*not* the C standard) that specify the _tolower macro do not, as far as I know, specify a particular implementation. For example, opengroup.org says: The _tolower() macro shall be equivalent to tolower(c) except that the application shall ensure that the argument c is an uppercase letter. The definition #define _tolower(_c) ((_c)-'A'+'a') happens to satisfy that definition for both ASCII and EBCDIC, but if an implementation were required for another character set, it could easily be provided (as a call to tolower() if nothing else). The standard does not guarantee that all lower case letters are continous and in exactly the same distance to another as in uppercase but it guaratees that if the input is not an uppercase letter it returns the value unchanged, so that thing ic completely crap. It would be completely crap if it were an implementation of the standard C tolower() function. It isn't. It's still the worst possible design for that function. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis (AT) CSi (DOT) com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Brian Inglis Guest Posted: Fri Sep 01, 2006 12:18 am    Post subject: Re: tolower macro On 10 Aug 2006 09:00:16 GMT in comp.lang.c.moderated, Keith Thompson <kst-u (AT) mib (DOT) org> wrote: Quote: There's no need for an implementation of tolower() to be portable. It just has to work correctly for a given implementation. The above macro doesn't satisfy this requirement, since it fails for (at least) characters other than upper case letters, but it could conceivably be ^ the 26 unaccented used by an implementation of tolower(). -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis (AT) CSi (DOT) com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Brian Inglis Guest Posted: Fri Sep 01, 2006 12:18 am    Post subject: Re: tolower macro On 25 Aug 2006 05:34:17 GMT in comp.lang.c.moderated, "Douglas A. Gwyn" <DAGwyn (AT) null (DOT) net> wrote: Quote: He might have been thinking that, but in fact what he showed us was the implementation of _tolower, which has a well-known standard specification that is in fact correctly met (on many platforms) by the exhibited implementation. Only for two (US) single byte character sets. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis (AT) CSi (DOT) com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Keith Thompson Guest Posted: Fri Sep 01, 2006 12:19 am    Post subject: Re: why still use C? "Malcolm" <regniztar (AT) btinternet (DOT) com> writes: [...] Quote: A compiler can accept anything and remain conforming. This is partly because it is impossible to test that every contorted example of bad syntax will be caught, parlty because so many compilers allow extensions. That's *almost* true; a comforming compiler must reject a program that contains a "#error" directive. The actual wording in the C99 standard (4p4) is: The implementation shall not successfully translate a preprocessing translation unit containing a #error preprocessing directive unless it is part of a group skipped by conditional inclusion. Quote: Constraint violations are examples of "bad grammar". For instance assigning an integer a pointer value. However often there is god reason for doing this, because integers and pointers are often stored in exactly the same registers, and it might be important to get the absolute value of a pointer, for instance implementing a %p option in a printf-like function. I think "grammar" is a poorly chosen word here. The grammar defines the *syntax* of the language; in that sense, "bad grammar" would be something like a missing semicolon or an extra parenthesis. I think of constraint violations as a different class of errors. For example this: int x = "foo"; is a constraint violation, but it doesn't violate the grammar. -- Keith Thompson (The_Other_Keith) kst-u (AT) mib (DOT) org <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Douglas A. Gwyn Guest Posted: Fri Sep 01, 2006 12:19 am    Post subject: Re: why still use C? Brian Inglis wrote: Quote: MS supports C89 and stated it has no intention of supporting C99. That's not what they have said; what they said was that they would implement C99 features as customer demand warranted. -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Brian Inglis Guest Posted: Mon Sep 18, 2006 5:29 am    Post subject: Re: why still use C? fOn 31 Aug 2006 19:19:04 GMT in comp.lang.c.moderated, "Douglas A. Gwyn" <DAGwyn (AT) null (DOT) net> wrote: Quote: Brian Inglis wrote: MS supports C89 and stated it has no intention of supporting C99. That's not what they have said; what they said was that they would implement C99 features as customer demand warranted. From: http://groups.google.ca/group/comp.lang.c/msg/faed0a6d66938197 I asked if MS has any plans to support C99 in the next VisualC. This is their answer. I think we should whine more :-) We feel that C++ addresses this space sufficiently. In general we have no plans to add any C99 features that duplicate functionality in C++ or conflict with it. That also matches the feedback we have gotten from customers. In fact the non interest in C99 is the clearest feedback I have seen of any issue. The ratio of customers who don't want us to prioritize C99 features versus those who do is definitely higher than 100:1. From: http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_022703.aspx Q: There is one single C99 feature that has grasped my desire: "varargs" macros. They rock! Will you be implementing these at some point? A: I happen to think there'll pretty cool as well. We haven't had a lot of demand for varargs macros. We happen to have an extension '__noop' which can be used for some of the same purposes varargs macros are (debuging printf's). Q: Follow-up on the C99 "varargs" question, what, if anything, from C99 will we see in the future from VC A: In general, we have seen little demand for many C99 features. Some features have more demand than others, and we will consider them in future releases provided they are compatible with C++. It is more likely we'll entertain C99 features if they are picked up in the next version of the C++ standard. Q: keyword restrict? A: We are definitely considering restrict. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis (AT) CSi (DOT) com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Robert Seacord Guest Posted: Mon Sep 18, 2006 5:29 am    Post subject: Re: why still use C? Thanks for all your responses. If you would like to review and comment on the "final" version of the secure coding rule I derived from all of this please see: https://www.securecoding.cert.org/confluence/display/seccode/EXP31-C.+Do+not+modify+constant+values Thanks, rCs -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Allan Adler Guest Posted: Mon Sep 18, 2006 5:29 am    Post subject: Re: sum(2,4,3,5,-1,...) I've learned enough from this discussion to know that one of the explicitly displayed arguments to a variable argument function has to contain enough information for the program to figure out how long the variable argument list is. I've also managed to write some functions I needed that involve variable argument lists. In one case, there were two arguments followed by a variable argument list. The first argument was a structure that contained, among other things, the length of the variable argument list and the second argument was a pointer to a function that gets called in the routine. The variable list of arguments are all structs of the same type as the first argument. It compiles and runs ok but I get the following complaint from the compiler: warning: second parameter of va_start not last named argument I'm ignoring it, since the program obviously works, but I'm wondering whether there is some way to make the warning go away. -- Ignorantly, Allan Adler <ara (AT) zurich (DOT) csail.mit.edu> * Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and * comments do not reflect in any way on MIT. Also, I am nowhere near Boston. -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Keith Thompson Guest Posted: Fri Sep 22, 2006 5:45 am    Post subject: Re: sum(2,4,3,5,-1,...) Allan Adler <ara (AT) nestle (DOT) csail.mit.edu> writes: Quote: I've learned enough from this discussion to know that one of the explicitly displayed arguments to a variable argument function has to contain enough information for the program to figure out how long the variable argument list is. I've also managed to write some functions I needed that involve variable argument lists. In one case, there were two arguments followed by a variable argument list. The first argument was a structure that contained, among other things, the length of the variable argument list and the second argument was a pointer to a function that gets called in the routine. The variable list of arguments are all structs of the same type as the first argument. It compiles and runs ok but I get the following complaint from the compiler: warning: second parameter of va_start not last named argument I'm ignoring it, since the program obviously works, but I'm wondering whether there is some way to make the warning go away. You're getting a warning message for code that you're not showing us. The message makes sense. The second argument to va_start() must be the last named parameter (i.e., the one just before the ", ..."). If you call it with something else, you get undefined behavior; if your program seems to work, it's only by chance. -- Keith Thompson (The_Other_Keith) kst-u (AT) mib (DOT) org <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top av Guest Posted: Fri Sep 22, 2006 5:48 am    Post subject: Re: meaning of strcat(p,p) -- was: managed string library Re: meaning of strcat(p,p) char* strcat(char* a, char* b) {char *p, *h; if(a==0 || b==0) return 0; for(p=a; *p; ++p) ; h=p if(a==b) {for(; b<h; ) *p++=*b++; *p=0; return a; } else while(b!=a && *p++=*b++); return b==a ? 0: a; } not tested... 0 for error and "strcat(p,p);" is ok (if p has right mem space) don't know for strcat(p, p+4); or strcat(p+4, p); -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Allan Adler Guest Posted: Tue Sep 26, 2006 12:22 am    Post subject: Re: sum(2,4,3,5,-1,...) Allan Adler <ara (AT) nestle (DOT) csail.mit.edu> writes: Quote: In one case, there were two arguments followed by a variable argument list. The first argument was a structure that contained, among other things, the length of the variable argument list and the second argument was a pointer to a function that gets called in the routine. The variable list of arguments are all structs of the same type as the first argument. It compiles and runs ok but I get the following complaint from the compiler: warning: second parameter of va_start not last named argument I'm ignoring it, since the program obviously works, but I'm wondering whether there is some way to make the warning go away. In response to requests for some actual code, I wrote another function that has a similar description and produces the same warning, but which is more easily taken out of its context. Here is the code (copied by hand): which resides a file named scratch.c: #include <stdio.h> #include <stdarg.h> struct measured_list { int length_of_list; int * list_of_int; }; int vararg_inner_product(struct measured_list * ml, int f(),...) { va_list ap; int i,j,k,m,n=0; m = ml->length_of_list; va_start(ap,m); for(i=0;i<m;i++) {j=ml->list_of_int[i]; n += f(j,va_arg(ap,int));} va_end(ap); return n; } int mult(int a, int b) {return a*b;} int mulist[5] = {3,1,4,1,6}; int main() { int i; char c,d; struct measured_list * myml; FILE * fp1, * fp2; myml = (struct measured_list *) malloc(sizeof(struct measured_list)); myml->length_of_list = 5; myml->list_of_int = mylist; i = vararg_inner_product(myml,mult,2,7,1,8,2); printf(i = %d\n",i); return 0; } It prints i = 37 and the compiler warning is: scratch.c: 14: warning: second parameter of 'va_start' not last named argument -- Ignorantly, Allan Adler <ara (AT) zurich (DOT) csail.mit.edu> * Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and * comments do not reflect in any way on MIT. Also, I am nowhere near Boston. -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top Dave Thompson Guest Posted: Tue Sep 26, 2006 12:22 am    Post subject: Re: sum(2,4,3,5,-1,...) On 18 Sep 2006 00:29:30 GMT, Allan Adler <ara (AT) nestle (DOT) csail.mit.edu> wrote: Quote: I've learned enough from this discussion to know that one of the explicitly displayed arguments to a variable argument function has to contain enough information for the program to figure out how long the variable argument Right. Or more precisely, the vararg callee must be able to determine the number of varargs and their types (in sequence) using only information it has _before_ accessing a given arg with va_arg; this can be from the fixed arg(s) (shared) globals, which are bad style, plus the previously (correctly) accessed varargs. Quote: list is. I've also managed to write some functions I needed that involve variable argument lists. In one case, there were two arguments followed by a variable argument list. The first argument was a structure that contained, among other things, the length of the variable argument list and the second argument was a pointer to a function that gets called in the routine. The variable list of arguments are all structs of the same type as the first argument. It compiles and runs ok but I get the following complaint from the compiler: warning: second parameter of va_start not last named argument I'm ignoring it, since the program obviously works, but I'm wondering whether there is some way to make the warning go away. As it says, invoke va_start using the last named (aka fixed) parameter (not strictly speaking argument). This is the only way guaranteed to work portably. If you specify any other parameter, it is possible for the compiler to screw up by starting to look in the wrong place(s) for the values of the varargs; if such code works on your compiler, apparently it is ignoring what you wrote and using what it knows. Especially since it labels this diagnostic as a warning; that usually means it thinks it has corrected the problem -- but the implementor's judgement/guess (far in advance) as to what you will have intended by a given dubious construct can easily be mistaken. Commonly, like printf, there is only one named/fixed parm, so choosing the right one is pretty easy. If your varargs are all the same fixed type, the other possibility is to put them in an array and 'pass the array' which is done in C by passing a pointer to the first element plus the count either explicitly or implied by some other information (such as a sentinel). If they are all the same type but it varies from call to call, you can still pass an array to a 'void *' or if all the possible types are structs to a 'struct dummy *' and then convert before using or fake the access(es) as if you had converted to the (or a?) correct type. - David.Thompson1 at worldnet.att.net -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Back to top        C++Talk.NET Forum Index -> C Language (Moderated) All times are GMT Goto page Previous  1, 2, 3 ... 8, 9, 10, 11, 12, 13  Next Page 9 of 13 Powered by phpBB © 2001, 2006 phpBB Group