Greetings!
I was recently surprised by the compiler's warning concerning this code:
struct text {
char* s;
size_t len;
};
int main() {
struct text t = {"hello world!"};
}
The compiler actually claimed that t.len was uninitialised. Okay, I don't
explicitly initialise it, but I was under the impression that it should be
initialised to zero then (i.e. all fields after the last one are
initialised with zero). Okay, it's just a warning, so I tended to ignore
it. Now, when I ran the code through Valgrind, it also complained that an
uninitialised value was used, which got me thinking. Lastly, I used gdb to
step through the code and explicitly shredded the value of t.len before
that line and - lo and behold - it was correctly (IMHO) reset to zero!
Now, I'm pretty sure about the rule with the additional fields, but I'm
wondering nonetheless. Can someone confirm or deny whether t.len above is
initialised or not?
thank you
Uli
19  1618 
On Dec 31, 12:58 pm, Ulrich Eckhardt <dooms...@knuut .dewrote:
Greetings!
I was recently surprised by the compiler's warning concerning this code:
struct text {
char* s;
size_t len;
};
int main() {
struct text t = {"hello world!"};
}
The compiler actually claimed that t.len was uninitialised. Okay, I don't
explicitly initialise it, but I was under the impression that it should be
initialised to zero then (i.e. all fields after the last one are
initialised with zero). Okay, it's just a warning, so I tended to ignore
That is true only for an array.
it. Now, when I ran the code through Valgrind, it also complained that an
uninitialised value was used, which got me thinking. Lastly, I used gdb to
step through the code and explicitly shredded the value of t.len before
that line and - lo and behold - it was correctly (IMHO) reset to zero!
Now, I'm pretty sure about the rule with the additional fields, but I'm
wondering nonetheless. Can someone confirm or deny whether t.len above is
initialised or not?
The standard doesn't say anything about initializing the rest members
to 0.
Using gdb to determine whether a program is correct or not is bad
practise, as it is to run the program and come to a conclusion by the
output.
Gdb is not a 'C99 tool'.
On Dec 31, 10:58*am, Ulrich Eckhardt <dooms...@knuut .dewrote:
Greetings!
I was recently surprised by the compiler's warning concerning this code:
* struct text {
* * char* s;
* * size_t len;
* };
* int main() {
* * struct text t = {"hello world!"};
* }
The compiler actually claimed that t.len was uninitialised. Okay, I don't
explicitly initialise it, but I was under the impression that it should be
initialised to zero then (i.e. all fields after the last one are
initialised with zero).
Indeed. Paragraph 21 of 6.7.8 of n1256 states:
If there are fewer initializers in a
brace-enclosed list than there are elements
or members of an aggregate, or fewer
characters in a string literal used to
initialize an array of known size than
there are elements in the array, the remainder
of the aggregate shall be initialized implicitly
the same as objects that have static storage
duration.
and paragraph 10 of the same clause states that
arithmetic types of static storage are initialized to 0.
Okay, it's just a warning, so I tended to ignore
it. Now, when I ran the code through Valgrind, it also complained that an
uninitialised value was used, which got me thinking.
Regarding the compiler perhaps it just warns you about
the lack of explicit initialization. Regarding valgrind I
don't know how it deals with such issues.
Now, I'm pretty sure about the rule with the additional fields, but I'm
wondering nonetheless. Can someone confirm or deny whether t.len above is
initialised or not?
According to the standard it should. Perhaps the person
who wrote your compiler was ignorant about that part of
the standard ? ;-) vi******@gmail. com writes:
On Dec 31, 12:58 pm, Ulrich Eckhardt <dooms...@knuut .dewrote:
>I was recently surprised by the compiler's warning concerning this code:
struct text {
char* s;
size_t len;
};
int main() {
struct text t = {"hello world!"};
}
The compiler actually claimed that t.len was uninitialised. Okay, I don't
explicitly initialise it, but I was under the impression that it should be
initialised to zero then (i.e. all fields after the last one are
initialised with zero).
<snip>
>Now, I'm pretty sure about the rule with the additional fields, but I'm
wondering nonetheless. Can someone confirm or deny whether t.len above is
initialised or not?
The standard doesn't say anything about initializing the rest members
to 0.
I think it does. 6.7.8 para. 21:
If there are fewer initializers in a brace-enclosed list than there
are elements or members of an aggregate, or fewer characters in a
string literal used to initialize an array of known size than there
are elements in the array, the remainder of the aggregate shall be
initialized implicitly the same as objects that have static storage
duration.
Further up (para. 10) explains that objects of static duration are
initialised to arithmetic zero or NULL by default.
--
Ben. vi******@gmail. com wrote:
On Dec 31, 12:58 pm, Ulrich Eckhardt <dooms...@knuut .dewrote:
>[Not explicitly initialised fields of a struct that is partially
initialised are implicitly initialised to zero. ]
Now, I'm pretty sure about the rule with the additional fields, but I'm
wondering nonetheless. Can someone confirm or deny whether t.len above is
initialised or not?
The standard doesn't say anything about initializing the rest members
to 0.
Well, that's where a few others and I disagree with you. Also, the compiler
only warns but still does the initialisation.
Using gdb to determine whether a program is correct or not is bad
practise, as it is to run the program and come to a conclusion by the
output. Gdb is not a 'C99 tool'.
Well, surely it is not a way to prove that the program is correct C.
However, I have four different opinions on whether the program is buggy:
1. Compiler
The compiler said something was uninitialised, which often causes errant
runtime behaviour, in my case it would have lead to calling free() with a
pointer to a string literal. Of course that is not a proof, since
uninitialised storage can contain anything, including a very deterministic
value.
2. Running
Running the program didn't cause any runtime errors, as free()ing a string
literal usually does. Same uncertainty as above though, but glibc otherwise
correctly detects this error.
3. Valgrind
Typically valgrind doesn't care too much about C but operates directly on
the generated machine code. The fact that it detects use of uninitialised
memory was what first prompted me to wonder whether there was something
behind the warnings emitted by the compiler.
4. GDB (a debugger)
I used the debugger to manually shred the memory of the variable that was
claimed to be not initialised. I observed that code was executed to lateron
initialise the variable to zero.
I'm aware that none of these tests are in any way mandated by any C
standard, but that's real life. ;)
Just for the interest of those that are reading this: the actual problem was
with my use of Valgrind. If I had paid a bit more attention to its output,
I would have seen that the errors are in fact detected in /lib/ld-2.3.6.so
and not in my executable. Actually using an uninitialised struct in my code
also causes it to be detected and reported as occurring in my code, so the
compiler output can be taken as "just a [stupid] warning".
Uli
On Dec 31, 6:02*am, Ulrich Eckhardt <dooms...@knuut .dewrote:
vipps...@gmail. com wrote:
On Dec 31, 12:58 pm, Ulrich Eckhardt <dooms...@knuut .dewrote:
[Not explicitly initialised fields of a struct that is partially
initialised are implicitly initialised to zero. ]
Now, I'm pretty sure about the rule with the additional fields, but I'm
wondering nonetheless. Can someone confirm or deny whether t.len above is
initialised or not?
The standard doesn't say anything about initializing the rest members
to 0.
Well, that's where a few others and I disagree with you. Also, the compiler
only warns but still does the initialisation.
Using gdb to determine whether a program is correct or not is bad
practise, as it is to run the program and come to a conclusion by the
output. Gdb is not a 'C99 tool'.
Well, surely it is not a way to prove that the program is correct C.
However, I have four different opinions on whether the program is buggy:
1. Compiler
The compiler said something was uninitialised, which often causes errant
runtime behaviour, in my case it would have lead to calling free() with a
pointer to a string literal. Of course that is not a proof, since
uninitialised storage can contain anything, including a very deterministic
value.
2. Running
Running the program didn't cause any runtime errors, as free()ing a string
literal usually does. Same uncertainty as above though, but glibc otherwise
correctly detects this error.
3. Valgrind
Typically valgrind doesn't care too much about C but operates directly on
the generated machine code. The fact that it detects use of uninitialised
memory was what first prompted me to wonder whether there was something
behind the warnings emitted by the compiler.
4. GDB (a debugger)
I used the debugger to manually shred the memory of the variable that was
claimed to be not initialised. I observed that code was executed to lateron
initialise the variable to zero.
I'm aware that none of these tests are in any way mandated by any C
standard, but that's real life. ;)
Just for the interest of those that are reading this: the actual problem was
with my use of Valgrind. If I had paid a bit more attention to its output,
I would have seen that the errors are in fact detected in /lib/ld-2.3.6.so
and not in my executable. Actually using an uninitialised struct in my code
also causes it to be detected and reported as occurring in my code, so the
compiler output can be taken as "just a [stupid] warning".
You do not use C software tools to determine if a program is correct
or not, you use the C standard. If (for instance) one of your tools
has a bug, then what will you conclude?
"user923005 " <dc*****@connx. comwrote in message
news:53******** *************** ***********@i3g 2000hsf.googleg roups.com...
On Dec 31, 6:02 am, Ulrich Eckhardt <dooms...@knuut .dewrote:
vipps...@gmail. com wrote:
On Dec 31, 12:58 pm, Ulrich Eckhardt <dooms...@knuut .dewrote:
[Not explicitly initialised fields of a struct that is partially
initialised are implicitly initialised to zero. ]
Now, I'm pretty sure about the rule with the additional fields, but I'm
wondering nonetheless. Can someone confirm or deny whether t.len above
is
initialised or not?
The standard doesn't say anything about initializing the rest members
to 0.
<snip>
>
I'm aware that none of these tests are in any way mandated by any C
standard, but that's real life. ;)
Just for the interest of those that are reading this: the actual problem
was
with my use of Valgrind. If I had paid a bit more attention to its output,
I would have seen that the errors are in fact detected in /lib/ld-2.3.6.so
and not in my executable. Actually using an uninitialised struct in my
code
also causes it to be detected and reported as occurring in my code, so the
compiler output can be taken as "just a [stupid] warning".
<
You do not use C software tools to determine if a program is correct
or not, you use the C standard. If (for instance) one of your tools
has a bug, then what will you conclude?
>
best practice is probably to find the least common denominator (of standard
and tools).
if the standard says something should work, but the tools are broken, then
maybe it makes sense to bend to the tools (not write that code, since the
tools are broke, and it is assumed here that the user is not one of the
tools' developers).
now, if the tools allow something, but the standard does not, then one goes
with the standard.
user923005 wrote:
You do not use C software tools to determine if a program is correct
or not, you use the C standard. If (for instance) one of your tools
has a bug, then what will you conclude?
Yes, in theory you could do so, but in practice the correct function of a
program is determined by whether it does the right thing and not by some
standard, not even if it is written in a certain language. Sorry, but your
point of view is simply unrealistic. If you had at least said "correct
according to the C standard" I would have agreed, but like that your
statement is just rubbish to me. Try to sell a program to a customer saying
that it's correct C while executing it behaves erratically.
Uli
On Jan 2, 9:57*pm, Ulrich Eckhardt <dooms...@knuut .dewrote:
user923005 wrote:
You do not use C software tools to determine if a program is correct
or not, you use the C standard. *If (for instance) one of your tools
has a bug, then what will you conclude?
Yes, in theory you could do so, but in practice the correct function of a
program is determined by whether it does the right thing and not by some
standard, not even if it is written in a certain language. Sorry, but your
point of view is simply unrealistic. If you had at least said "correct
according to the C standard" I would have agreed, but like that your
statement is just rubbish to me. Try to sell a program to a customer saying
that it's correct C while executing it behaves erratically.
If it is correct C and executes erratically, then your tools are
broken. Switch tools.
If it is incorrect C and yet it appears to execute correctly, then it
is (in fact) broken. When the compiler is repaired and maintenance
work is done on the code, then it may no longer function. Or the
undefined behavior may surface at the most inopportune time, such as
when an Arianne missile takes off.
Why do you imagine that ISO bothers to write standards for languages?
For exactly the same reason that they write standards for bolts and
for oil and for just about everything else under the sun that might be
used to create products. If there is an accurate design specification
that describes exactly how something *must* behave then we can code to
that standard. It is this engineering approach that leads to accurate
and reliable systems. It is your "seat of the pants" approach that
leads to cowboy coding and people getting fried by x-ray machines.
user923005 wrote:
On Jan 2, 9:57*pm, Ulrich Eckhardt <dooms...@knuut .dewrote:
>user923005 wrote:
You do not use C software tools to determine if a program is correct
or not, you use the C standard. *If (for instance) one of your tools
has a bug, then what will you conclude?
Yes, in theory you could do so, but in practice the correct function of a
program is determined by whether it does the right thing and not by some
standard, not even if it is written in a certain language. Sorry, but
your point of view is simply unrealistic. If you had at least said
"correct according to the C standard" I would have agreed, but like that
your statement is just rubbish to me. Try to sell a program to a customer
saying that it's correct C while executing it behaves erratically.
If it is correct C and executes erratically, then your tools are
broken. Switch tools.
This is ridiculous. Have you considered that there are only so many
resources for your goals and that switching tools might just not be an
option?
If it is incorrect C and yet it appears to execute correctly, then it
is (in fact) broken.
This obviously depends on the definition of broken, whether it simply
means "incorrect C" or "behaves faulty". In one case, you say "if it is
incorrect C, then it is incorrect C", duh. In the other case you say "if it
behaves correctly and is incorrect C, it behaves faulty". One statement is
obviously correct, the other obviously rubbish. Am I perhaps missing a
third definition of "broken"?
When the compiler is repaired and maintenance work is done on the
code, then it may no longer function. Or the undefined behavior
may surface at the most inopportune time, such as when an Arianne
missile takes off.
So? Bugs happen. Testing helps against shipping broken code. What is it that
you do with the standard that helps you against shipping buggy programs?
Why do you imagine that ISO bothers to write standards for languages?
For exactly the same reason that they write standards for bolts and
for oil and for just about everything else under the sun that might be
used to create products. If there is an accurate design specification
that describes exactly how something *must* behave then we can code to
that standard. It is this engineering approach that leads to accurate
and reliable systems.
Dude, you don't get it: if the observable behaviour of a program is correct,
it eventually doesn't matter to e.g. a customer if this behaviour relies on
undefined behaviour or not. In fact pretty many programs rely at least on
implementation-defined behaviour. OTOH, if the behaviour is incorrect, it
similarly doesn't matter if it complies to any standard or not, you will
not be able to sell it. This is reality, and I don't understand why you
keep arguing that.
It is your "seat of the pants" approach that
leads to cowboy coding and people getting fried by x-ray machines.
Whining about standard compliance doesn't help if you get fried. Your
real-world program must behave, even if it is compiled by real-world,
non-perfect tools. Using real-world, non-perfect tools to find errors is
the only choice we (i.e. the people living in the real world) have, the C
standard is not a tool that can be efficiently used to find errors, you can
only use it to distinguish between a bug in your program and in the
implementation, once you found it.
Uli This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Sagaert Johan |
last post by:
does c# provide bitfields in structs ??
can't find any hint in msdn
Johan
|
by: Charles Law |
last post by:
Sorry for asking this one again, but with the newsgroup now holding things
for an ever shorter time, I can't find my original question (and the
answers) from a few months ago.
I know that structures in VB.NET don't have bit fields, but I am looking for
a convenient way to reproduce the convenience afforded in C/C++.
If I have
typedef struct _MyStruct {
|
by: santosh |
last post by:
Hi,
If I call free() with a uninitialised pointer, will the program
state become undefined, or will free() return harmlessly?
Incidentally, is there a way in Standard C to determine
weather a pointer points to a valid block of allocated
memory?
Thanks for your time.
|
by: dissectcode |
last post by:
Hi everyone - I was reading in the K&R C book (on page 150) that (Bit) Fields are assigned left to right on some machines and right to left on others. This means listing the bit fields from most significant to least, or vice versa.
So I am creating a couple header files for drivers which contain structures of all the relevant bit fields....I need to "test" how my company's compiler orders the bit fields.
I was thinking about creating a...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
| | |
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
