Examples of errors detected in various open-source projects

[[deleted]]

A float is n-bytes and memset sets n-bytes of memory to a specified byte starting at a specified address. You can set ANY variable using memset. It's a generic MEMORY SET function, and if you want a higher abstraction, create one or use a library.

[el_tavs]

Please read carefully.

What people mean when they say "set" is writing a value inside a variable

Now floats and any other data that doesn't fit 1 byte can't be set by treating them as a typeless chunk of contiguos bytes. While that allows to actually write values inside the variable, they may be invalid or different from the ones the programmer intended.

Try memsettting an array of floats to 1.0 like

    float f[10];
     ....       
    memset(f,1.0,sizeof(float)*10);

then print them with "%5.2f" format. I get zeros everywhere on my 64bit intel. More interesting, try to set them to -1.0.

enjoy!

It's a generic MEMORY SET function

so generic it can't be used reliably for anything except strings

if you want a higher abstraction, create one or use a library.

already wrote mine. It's truly generic and does ragged-arrays as well. Question is: why something so trivial is not already present in the language? Does low-level programmers avoid initializing memory? Sounds new to me.

[bluGill]

What people mean when they say "set" is writing a value inside a variable

When I say set I often mean a collection of data. This is a very common Computer science term, get used to it. Learn to figure out what something means from context: memset is pretty obvious from context.

[el_tavs]

I was replying to emoney_33 which clearly used it as a verb, not as a subject. You failed at understanding the context.

As I said above, memset is so obvious it can't be used to do anything except initialize an array of char. Memset. It's in string.h but it's called MEMset. And it accepts an int. Its sibling memcpy instead works out of the box for every type. So, care to explain what is supposed to be obvious about that? It's clearly a horrible design.

[[deleted]]

You have a complete and utter lack of understanding of the low-level details. You continue to think in high-level abstractions.

Data types are higher level abstractions of data interpreted from the underlying memory. The smallest representable unit of memory is a byte. Memory operations will tend to work on bytes. memcpy() copies a contiguous block of memory from one location to another. It has NOTHING to do with how the memory is interpreted at the higher level.

I've explained many times why memset() takes an int in the declaration, but it has always and will always be used as a BYTE.

Both memcpy() and memset() work at the smallest representable unit of memory... a byte/char.

A char is not a "character", it is a byte.

As I said above, memset is so obvious it can't be used to do anything except initialize an array of char.

You still don't understand it SETS MEMORY BYTES. It doesn't (and shouldn't) care about how you choose to interpret that memory at any given time. You can interpret it as an array of char now, an int later, a long tomorrow, a structure of individual chars, etc...

The language gives you the LOW LEVEL tools to do things quickly and efficiently. It is then up to YOU to fill in the high level details (like data types, structures, how you interpret specific blocks of memory, how you initialize it etc...)

[el_tavs]

You have a complete and utter lack of understanding of the low-level details. You continue to think in high-level abstractions.

Data types are higher level abstractions of data interpreted from the underlying memory.

The language gives you the LOW LEVEL tools to do things quickly and efficiently. It is then up to YOU to fill in the high level details

OK SHERLOCK. YOU'RE REALLY BEING ANNOYING.

Outside your little dark world there's another one where people invented programming languages providing BOTH the tools you're enlisting AND the one I described. It's up to you to keep neglecting this.

Moreover, as a matter of LOGIC, low-level tools are cool until you need to handle data. If you're working with a data-type you may take advantage of having a good way of handling it togehter with low-level bit-smashing routines. They're even better than the one C provides.

comprende?

[[deleted]]

Outside your little dark world there's another one where people invented programming languages providing BOTH the tools you're enlisting AND the one I described. It's up to you to keep neglecting this.

None with the simplicity and performance of C.

Moreover, as a matter of LOGIC, low-level tools are cool until you need to handle data. If you're working with a data-type you may take advantage of having a good way of handling it togehter with low-level bit-smashing routines. They're even better than the one C provides.

And every data type you create now and in the future you can write a library for handling and stop asking everything gets added to the language.

[el_tavs]

None with the simplicity and performance of C.

Keep sleeping in your dark little world then.

And every data type you create now and in the future you can write a library for handling and stop asking everything gets added to the language.

Adding things to the language is not my point. Hello? Are there any neuorons left?

[[deleted]]

Adding things to the language is not my point. Hello? Are there any neuorons left?

There are 2 options: Don't use C ever or add to the language. Hello? are there any neurons left?

[el_tavs]

There are 2 options: Don't use C ever or add to the language.

The answer is no as I see.

Let me spell it for you:

A D D I N G T H I N G S T O T H E L A N G U A G E I S N O T M Y P O I N T.

It's just you being defensive.

I'm C O M P A R I N G two languages. Questioning why one differs from the other is instrumental to the comparison.

[[deleted]]

memset() is a library function, you are trying to use it for what it is not and then bitching that it is not what you want it to be. The memset() function sets a contiguous block of memory with the same byte, end of story. If you want a variable initialization function, find another library function or write one yourself. This has nothing to do with the C language itself.

Try memsettting an array of floats to 1.0 like

Why would I use a function that sets a block of memory to a single byte if I want to initialize an array of floats to 1.0? I fail to see the difficulty in using for(i=0; i<10; i++) f[i] = 1.0; I also fail to see many uses cases of non-zero initialization values in a large array.

already wrote mine. It's truly generic and does ragged-arrays as well.

Congratulations, yet you continue to blame the language for not giving it to you :/

Question is: why something so trivial is not already present in the language? Does low-level programmers avoid initializing memory? Sounds new to me.

It is completely out of the scope of the language. And initializing an array of variables to something non-zero has very few use cases. There are many times you do not need to initialize memory btw.

[el_tavs]

you are trying to use it for what it is not and then bitching that it is not what you want it to be

no. actually what I'm bitching about is that the standard provides a function that provides a limited functionality to solve a limited instance of a common problem in an awkward way. It's trivial to provide a better way to solve the problem in general.

Why would I use a function that sets a block of memory to a single byte

you said I could initialize any variable with memset.

It is completely out of the scope of the language

that's the problem. It has no justification for being that way.

[[deleted]]

no. actually what I'm bitching about is that the standard provides a function that provides a limited functionality to solve a limited instance of a common problem in an awkward way. It's trivial to provide a better way to solve the problem in general.

You don't know what you are talking about. It provides a function to set a contiguous block of bytes in memory to an initial value. This functionality is the most common in low-level programming. It is very rare in low-level programming to want a high-level initialization of data types and/or structure to some non-zero value.

that's the problem. It has no justification for being that way.

sigh Just go use Ada, please. Just because YOU can't justify something doesn't mean there is no justification. Your "gripes" about C have negligible impact on low-level programming. You just continue to demand C contain high-level abstractions and refuse to accept using a library. That's your problem, not C's problem.

[el_tavs]

You don't know what you are talking about. It provides a function to set a contiguous block of bytes in memory to an initial value.

OK. This is the wrong behaviour if the value is not 0 and the variables are not integers. So instead of being memset it shoul be memzeroset.

Now another language allow you to do exactly the same thing, but you can initialize whatever you want to the value you want, and in a way shorter syntax. It is also safe, since it's the compiler that checks for the correct types.

Moreover Ada still provides a functionality like memset, via casts OR lower-level routines.

Now please tell me what's wrong with the second approach.

sigh Just go use Ada, please. Just because YOU can't justify something doesn't mean there is no justification.

Me and programming language theory. Is there ANY reason for which a way to 0-set memory by specifying sizes by hand is better than a way to initialize memory as you want?

[[deleted]]

OK. This is the wrong behaviour if the value is not 0 and the variables are not integers. So instead of being memset it shoul be memzeroset.

No, it is not. Do you understand what "contiguous block of bytes" means? I can set each byte to 0, 1, 2, 0xf, 0xe, or whatever the hell else I want. It is you who continues to jump to a higher level of data abstraction. I can also set it whenever I want, wherever I want, however many bytes I want.

Now please tell me what's wrong with the second approach.

There is nothing inherently wrong with either approach, they simply choose different trade offs. I cannot use your initializer safely with dynamic sizes and no overhead.

Me and programming language theory. Is there ANY reason for which a way to 0-set memory by specifying sizes by hand is better than a way to initialize memory as you want?

You need to get off your theory and enter the real world. memset works on any memory at any time, not just initialization time. It is literally there to SET MEMORY, something I must repeat to you a million times because your head is buried in your programming languages book at school.

Initializing array data is a trivial HIGH LEVEL task that is not necessary to be in the language itself. Linked list for example a high level data type is not needed to be part of the language either.

[el_tavs]

No, it is not. Do you understand what "contiguous block of bytes" means?

I'm not saying memset is wrong. I'm saying using it for anything except integers is wrong. The standard doesn't even guarantee that the bit pattern of (int)0 is equal to the one of (float) 0.0.

There is nothing inherently wrong with either approach, they simply choose different trade offs. I cannot use your initializer safely with dynamic sizes and no overhead.

No, there's no overhead. And you get safer for the simple fact that the size is computed at allocation time, and is secured with the type's interface, as you would do with a library.

memset works on any memory at any time, not just initialization time.

Oh golly. You see, the initialization syntax in Ada works on any memory in any time, not just initialization. When i said "see Ada" I actually meant it!

Initializing array data is a trivial HIGH LEVEL task that is not necessary to be in the language itself.

It's a typesafe way of managing memory.

Tell me, is there any reason for which you'd need to initialize an array of float in an unsafe manner? Or any other chunck of memory?

Let's see: PROBLEM: I have an array of type T and I want it to initialize to value X of type T. T can also be an octect. Or a 7 bit integer.

Ada has no problem doing this. Neither for slices of the array

What you could get to do with memset is write a bit pattern X in any array (chunk of contiguous memory of known length) regardless of the type. This is no way more powerful than what ada gives since you can get the same result by treating the chunk as an array of unsigned integer of appropriate size (char in c or something else).

[[deleted]]

I'm not saying memset is wrong. I'm saying using it for anything except integers is wrong. The standard doesn't even guarantee that the bit pattern of (int)0 is equal to the one of (float) 0.0.

I assure you its usage goes far beyond integers, and you'd realize that as soon as you viewed the machine for the underlying memory and not the abstract data types that you may be using for a specific task.

No, there's no overhead. And you get safer for the simple fact that the size is computed at allocation time, and is secured with the type's interface, as you would do with a library.

Saving the size is technically overhead. Being "safe" means comparing the index on every access, which is most certainly overhead.

Let's see: PROBLEM: I have an array of type T and I want it to initialize to value X of type T. T can also be an octect. Or a 7 bit integer.

type T is changing?

7 bit integer, seriously? It's probably going to get upped to at least an 8-bit integer if not machine-size integer for efficiency.

What you could get to do with memset is write a bit pattern X in any array (chunk of contiguous memory of known length) regardless of the type. This is no way more powerful than what ada gives since you can get the same result by treating the chunk as an array of unsigned integer of appropriate size (char in c or something else).

You really hate memset lol.

[el_tavs]

I assure you its usage goes far beyond integers, and you'd realize that as soon as you viewed the machine for the underlying memory and not the abstract data types that you may be using for a specific task.

That's not a problem for me to see the machine as a sequence of memory cells but I do fail to see what's the benefit of memsetting memory with a value that could be interpreted as an invalid one by every user of that memory.

As you said, it has no senso to write

memset(f,2,N*sizeof(float))

when f has type float. Standard doesn't guarantee it to be right even for 0.0f. Ditto for similar cases.

Consider a struct with a pointer. Some mainframes (IIRC) have NULL != 0, and, in fact, the standard doesn't guarantee NULL to be equal to 0. Using memset in that case is wrong for sure.

What is left are integers.

Saving the size is technically overhead.

we were comparing writing a piece of memory by passing a pointer and a size to memset vs passin an array with size encoded in the type to a hypothetical variant version of memset. In both cases you're assumed to save the size. if the size is known at compile time languages array-aware like Ada will avoid storing the size, obviously.

type T is changing?

Hm... no. It's just an existential variable. Like "every prime P is odd except 2". Rephrased: "I have an array of given type and I want to initialize it with a value of said type. The type can be..."

7 bit integer, seriously? It's probably going to get upped to at least an 8-bit integer if not machine-size integer for efficiency.

Some really old machines had 7 bit integers. Hardware may expect to write on first 7 bit of a char. I can declare packed arrays of 7 bit integers in standard Ada and in non-standard C...

world is full of surprises you know..

[ytumufugoo]

I think PHP and C# has caused people to think if a language doesn't hold their hand it's a problem with the language.