| comp.lang.c++@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
- argv - 4 Updates
- sscanf and 0x80000000 - 13 Updates
- Onwards and upwards - 1 Update
- data type class and variable also a class. what does this mean? - 3 Updates
- Slow std integer to a string conversion (to_string/sprintf) - 4 Updates
| agent@drrob1.com: Nov 04 06:16PM -0500 I am trying to learn c++ after many years of using modula-2 and more recently ada. I am attempting this under ubuntu 14.04 amd64 version. #include <iostream> int main (int argc, char* argv[]) { char ch; ch = argv[argc][0]; // this line gives a seg fault return 0; } I don't understand why I'm getting a seg fault. I am trying to examine the byte that is supposed to be nullptr, and I'm having a tough time of it. To my understanding, the expression argv[argc][0] returns a char. Why is this wrong? Thanks |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 04 11:22PM > tough time of it. > To my understanding, the expression argv[argc][0] returns a char. > Why is this wrong? argc is a count of arguments argv[0] to argv[argc-1]. argv[argc] is array bounds overflow. /Flibble |
| red floyd <no.spam@its.invalid>: Nov 04 03:26PM -0800 On 11/4/2014 3:22 PM, Mr Flibble wrote: >> Why is this wrong? > argc is a count of arguments argv[0] to argv[argc-1]. argv[argc] is > array bounds overflow. It's not array bounds overflow. The value of argv[argc] is well defined. It's NULL. The issue the OP is seeing is dereferencing a NULL pointer. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 04 11:34PM On 04/11/2014 23:26, red floyd wrote: > It's not array bounds overflow. The value of argv[argc] is well > defined. It's NULL. The issue the OP is seeing is dereferencing > a NULL pointer. *Logically* it is array bounds overflow if not *physically*. /Flibble |
| Andrew Cooper <amc96@cam.ac.uk>: Nov 03 11:32PM On 03/11/2014 20:19, Christopher Pisz wrote: > determine the difference between a valid value of zero and an error > please, for my own education is solving this bug that occurs countless > times. errno = 0; val = strtoul(some_str, NULL, 0); if ( errno ) // Some error. val undefined else // val is good, even if 0. ~Andrew |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 04 12:14AM > On 03/11/2014 20:19, Christopher Pisz wrote: <snip> > // Some error. val undefined > else > // val is good, even if 0. No, that's wrong in a couple of ways. When no conversion can be done, zero is returned and errno is not set, and when errno is set val is not undefined -- it must be ULONG_MAX. -- Ben. |
| Andrew Cooper <amc96@cam.ac.uk>: Nov 04 01:06AM On 04/11/2014 00:14, Ben Bacarisse wrote: > No, that's wrong in a couple of ways. When no conversion can be done, > zero is returned and errno is not set, and when errno is set val is not > undefined -- it must be ULONG_MAX. Fine - sticking strictly to C and not relying on POSIX (not that there is any reasonable excuse for avoiding POSIX if it is available): errno = 0; val = strtoul(some_str, &endptr, 0); if ( errno || (endptr == some_str) ) // Some error. val as about as useful as being undefined. else // val is good, even if 0. ~Andrew |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 04 01:32AM >> undefined -- it must be ULONG_MAX. > Fine - sticking strictly to C and not relying on POSIX (not that there > is any reasonable excuse for avoiding POSIX if it is available): I think POSIX only says that strtoul *may* fail with errno == EINVAL when there is no conversion (the "false zero" return case), so I don't think you can reply on that, even with the POSIX extensions. <snip> -- Ben. |
| Juha Nieminen <nospam@thanks.invalid>: Nov 04 07:56AM > The general consensus on projects I've working on is the <cxxx> headers > are a wast of time: if you are using the C standard library functions, > don't try and hide them. Personally, I prefer not to pollute the global namespace. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| "Jouko Koski" <joukokoskispam101@netti.fi>: Nov 04 10:16AM +0200 "Juha Nieminen" wrote: >> are a wast of time: if you are using the C standard library functions, >> don't try and hide them. > Personally, I prefer not to pollute the global namespace. Well, the C standard library functions are in the global namespace already, aren't they? C++ headers just draw them to the std namespace, too. Some C++ headers declare additional things like overloaded functions in the std namespace. A bit of a mess! Has anybody seen a summary of how this is supposed to work and how it really works? -- Jouko |
| Martijn Lievaart <m@rtij.nl.invlalid>: Nov 04 09:16AM +0100 On Tue, 04 Nov 2014 01:06:26 +0000, Andrew Cooper wrote: >> undefined -- it must be ULONG_MAX. > Fine - sticking strictly to C and not relying on POSIX (not that there > is any reasonable excuse for avoiding POSIX if it is available): Why rely on POSIX when it isn't needed? One could argue that one can use strtoul the way you showed if Posix compliency is known, but this may create a proting bug later on. Why risk it if the alternative is one comparison extra? > // Some error. val as about as useful as being undefined. > else > // val is good, even if 0. This thread is a good example why streams can be easier than the C equivalents. Note I don't find streams easier to use when formatting output over the C equivalents, but for input i do. M4 |
| Juha Nieminen <nospam@thanks.invalid>: Nov 04 12:37PM > Well, the C standard library functions are in the global namespace already, > aren't they? I don't think you can rely on that. IIRC the newest gcc does not bring them to the global namespace if you use the <c...> versions. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| peter koch <peter.koch.larsen@gmail.com>: Nov 04 05:11AM -0800 Den tirsdag den 4. november 2014 08.56.52 UTC+1 skrev Juha Nieminen: > > are a wast of time: if you are using the C standard library functions, > > don't try and hide them. > Personally, I prefer not to pollute the global namespace. If I remember correctly, the <c....> equivalents may - and often do - pollute the global namespace as well. So using the <c....> includes only obscures the fact that the global namespace is/might be polluted for the user. This also risks making your code non-portable because using a global namespace function (e.g. printf) will not be detected by the compiler. /Peter |
| "Jouko Koski" <joukokoskispam101@netti.fi>: Nov 04 04:15PM +0200 "Juha Nieminen" wrote: >> already, >> aren't they? > I don't think you can rely on that. Yes, it is not mandated by the standard, but it is allowed by the standard. All real implementations I have seen implement the <cxxxxx> headers like this: #include <xxxxx.h> namespace std { using ::func; } That's why I asked if anybody has summarized how this is supposed to work and how it really works. Are we any better off with <cxxxxx> headers than without them? Ok, the overloaded functions have to go somewhere, but still? I think a standard C library function - say, sscanf - could well have stayed in the global namespace. If there were any ambiguity, one can easily resolve it by writing ::sscanf vs. somethingelse::sscanf. Having std::sscanf does not help much, unless one just likes have the std:: because it is used elsewhere - like say, with std::string - too. -- Jouko |
| Rosario193 <Rosario@invalid.invalid>: Nov 04 05:26PM +0100 On Fri, 31 Oct 2014 22:43:23 +0100, Marcel Mueller >The goal is to read an unsigned number in all common formats (decimal, >binary, octal, hex) from a string. The string does not necessarily end >after the number. I did not find format specifier that does the job. Borland compiler compile the progr that return print: 80000000 what about: #include <stdio.h> int main(void) { unsigned i; sscanf("0x80000000", "%x", &i); printf("%x", i); return 0; } |
| "Öö Tiib" <ootiib@hot.ee>: Nov 04 09:59AM -0800 On Tuesday, 4 November 2014 18:26:46 UTC+2, Rosario193 wrote: > printf("%x", i); > return 0; > } Assembler text may contain decimal, octal and hexadecimal numeric constants. OP wanted to handle all cases with single 'sscanf'. He wanted input "042" resulting with 'i' being 34, input "42" resulting with 'i' being 42 and input "0x42" resulting with 'i' being 66. What answers gives your borland to those inputs? |
| Rosario193 <Rosario@invalid.invalid>: Nov 04 08:15PM +0100 On Tue, 4 Nov 2014 09:59:31 -0800 (PST), 嘱 Tiib wrote: >He wanted input "042" resulting with 'i' being 34, >input "42" resulting with 'i' being 42 >and input "0x42" resulting with 'i' being 66. yes i understand now... thank you for that i would use strtoul().... >What answers gives your borland to those inputs? for the C op code above it print: "80000000"... |
| woodbrian77@gmail.com: Nov 04 09:42AM -0800 > C++ code generator. > I have time to make improvements to the software > and docs so don't be shy. I'm afraid the community is missing out on an opportunity here. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| "K' Dash" <adnanrashidpk@gmail.com>: Nov 04 01:38AM -0800 GUID_address GUID::function(int x, int y) what does this mean. GUID_address is class name where GUID is also a class name. where function(int x, int y) exsit in GUID.h. can any one explain it what is going on this line? |
| Martijn Lievaart <m@rtij.nl.invlalid>: Nov 04 11:39AM +0100 On Tue, 04 Nov 2014 01:38:50 -0800, K' Dash wrote: > GUID_address is class name where GUID is also a class name. where > function(int x, int y) exsit in GUID.h. > can any one explain it what is going on this line? This line by itself is meaningless. Maybe it looks like this? GUID_address GUID::function(int x, int y) { // ... implementation here } In that case it is the definition of the class member function GUID::function(int,int) declared in the header. M4 |
| FredK <fred.l.kleinschmidt@gmail.com>: Nov 04 07:22AM -0800 On Tuesday, November 4, 2014 2:40:13 AM UTC-8, Martijn Lievaart wrote: > } > In that case it is the definition of the class member function > GUID::function(int,int) declared in the header. First of all, "function" is a terrible name for a function. an easier way to see what's going on, lets define function abc in class GUID as int GUID::abc(int a, int b) {...} Here, abc is a fuinction that takes two integer arguments and returns an int. using this pattern, the above definition for "function" defines a function named "function" that takes two integer arguments and returns an instance of class GUID_address. -- Fred K |
| Luca Risolia <luca.risolia@linux-projects.org>: Nov 04 01:27AM +0100 Il 03/11/2014 17:47, Martijn Lievaart ha scritto: > What if i is slightly smaller than std::numeric_limits<unsigned>::max()? > In that case Y would eventually not fit an unsigned, resulting in an > infinite loop. I think that case is not possible. X can vary from 1 to std::numeric_limits<unsigned>::digits10 (included), which implies that the greatest Y is Y0 = 10^std::numeric_limits<unsigned>::digits10, where std::numeric_limits<unsigned>::digits10 is one less than the number of decimal digits needed to represent the maximum unsigned value std::numeric_limits<unsigned>::max(). For i >= Y0, there is the g<std::numeric_limits<unsigned>::digits10 + 1>() template specialization, but no Y is calculated there. |
| Martijn Lievaart <m@rtij.nl.invlalid>: Nov 04 08:59AM +0100 On Tue, 04 Nov 2014 01:27:22 +0100, Luca Risolia wrote: > std::numeric_limits<unsigned>::max(). For i >= Y0, there is the > g<std::numeric_limits<unsigned>::digits10 + 1>() template > specialization, but no Y is calculated there. Buzz. Think again. I see at least two errors in this explanation. M4 |
| Luca Risolia <luca.risolia@linux-projects.org>: Nov 04 10:44AM +0100 Martijn Lievaart wrote: >> g<std::numeric_limits<unsigned>::digits10 + 1>() template >> specialization, but no Y is calculated there. > Buzz. Think again. I see at least two errors in this explanation. Please be clear, define a way to reproduce the case where the algorithm would "eventually" result in an infinite loop in your opinion. Unfortunately, I cannot spend much time on this topic which was initially supposed to take me no more than 5 minutes. |
| Martijn Lievaart <m@rtij.nl.invlalid>: Nov 04 11:51AM +0100 On Tue, 04 Nov 2014 10:44:33 +0100, Luca Risolia wrote: > would "eventually" result in an infinite loop in your opinion. > Unfortunately, I cannot spend much time on this topic which was > initially supposed to take me no more than 5 minutes. If X equals std::numeric_limits<unsigned>::digits10, Y cannot be represented in an unsigned, so the result is implementation defined, but at most std::numeric_limits<unsigned>::max. So if i is std::numeric_limits<unsigned>::max, it will never be smaller than Y, resulting in unbounded recursion. For any i >= pow(10u, Y) where Y == std::numeric_limits<unsigned>::digits10, either the result is wrong, or unbounded recursion occurs. To make it simple, assume 8 bits. std::numeric_limits<unsigned>::digits10 == 3 => Y should be 1000, but that cannot be represented in 8 bits. (I know an unsigned cannot be 8 bits, that is not the point). M4 |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment