#define Question
 

I am not familar with the pipes with the values. What value does OBJECT_ID_tag have in this context?

Your question is very strange from a number of points of view:

1. OBJECT_ID_tag conceptually is no different from, say INTEGER_tag, so why are you asking specifically about OBJECT_ID_tag ?
2. what do pipes have to do with the above ?

.

At all, have you ever heard of bitwise operations in "C" and other languages and/or about bitfields and operations on/over/with them ?

I have a C program that builds and sends snmp traps. Been trying to port this program from Solaris to Linux. I ran the program using valgrind and it says there is a Memory Fault on the bolded build_tag() function below when the OBJECT_ID_tag is the first parm.

I have no idea why so I am trying diagnose what's going on.


/* valgrind error message*/
==1072== Invalid write of size 1
==1072== at 0x410A8C: build_tag (ber.c:160)

You haven't answered my questions which makes my suspicions even stronger. The suspicions are that you lack very basic knowledge in "C"/programming in general.

Please answer my questions first.

If I'm not clear, the very first sentence of yours:

makes me very suspicious - the question indicates you simply do not know what '|' character means, and this knowledge belongs to the category of very basic knowledge of "C".

Or, to put it bluntly, the quoted very first sentence of yours invalidates the whole question or, in other words, makes it senseless/pointless.

Wow, that's quite an attitude your packing there.

The "|" I referenced represents a Bitwise OR operation. My extreme apologies for calling it a pipe. What was I thinking.

Since I am not an expert, unlike yourself, I tend to ask questions in the spritit of LinuxQuestions dot org.

We can't read your mind. Calling the bitwise OR operator a "pipe" was enough to completely obscure the nature of your question (given that you also provided so little basic info about your question).

I couldn't have done a better job than Sergei at trying to guess what you meant and/or explain why you needed to ask the question in a way we can understand. There really was nothing wrong with Sergei's "attitude".

Back on topic:

I'm not sure I trust valgrind in this situation, but assuming we trust it, or just because you gave no other hint of what we need to look at:

We would need to see the declaration of ucPacket and the definition of build_tag in order to get some idea about the problem that you want us to help you with.

So, then the next part of your question remains:

.

I.e., taking into account your clarification and substituting 'pipes' with "Bitwise OR operation", your question/statement is legitimately transformed into:

I am not familiar with "Bitwise OR operation" with numbers.

And I have already addressed this in my reply - you need to learn about bitfields and operations over/on/with them.

Your (transformed) question still doesn't make sense to me - because it may imply that you do know about bitwise operations, but just do not know about bitwise operations in case one of the operands is a number.

I suggest to enter

C bitwise bitfield bitmask

into your favorite WEB search engine - the above search items are common knowledge. You might also spell the search query this way:

C bitwise bit field mask
.

From your post regarding SNMP it looks like you are dealing with SW working pretty closely to/with HW. In such a case knowledge of bitwise operations and bit fields/masks is an absolute must.

Conceptually your question is very similar to a request to explain how, say, multiplication works in terms of additions, or how addition is performed in a radix system and how/what for carry in/out is used - again, it's a common basic knowledge.

/* On Linux */
printf ("Pointer Before Start of Encoding : %p\n", ucPacket);

0x7feffcb20

/* On Solaris */
printf ("Pointer Before Start of Encoding : %p\n", ucPacket);

ffbebffc

What sense do

have ? I.e. what sense does a hexadecimal pointer value make to an outside observer if only one pointer value is displayed ? Had it been zero, it would have been an indication of something, but since it's a non-zero pointer, what conclusions can be made ?

My point is that pointer values make sense relative to each other (no, I don't mean Linux relative to Solaris) taking into account object sizes.

So, in more general terms, why/what for just a pointer value and nothing else is printed ? I.e. what kind of debugging methodology is it supposed to reflect ?

I am just trying to find the differences between Solaris and Linux and having the extra "0x7" in there on the Linux env seemed noteworthy. I guess it's not.

Look, I'm serious - (re)learn "C". Your questions and your approaches make no sense to me whatsoever.

Your attitude makes no sense to me. Look, I'm serious learn some "Manners".

-- OFFTOPIC --

Sergei Steshenko: A personal request, if I may. Could you please not start your posts with a "Quote" of the whole post you are replying to, espcially when you are replying to the last post in a thread? It is fairly disturbing when reading the thread top to bottom (and not only).

If I also may, you said: "Your questions and your approaches make no sense to me whatsoever.". Why do you not give up on the thread, then? Your posts would seem to indicate that SeymourButts has been irrefutably denied help in this matter. This is not for you to decide. The thread's reply count keeps getting incremented, and potential helpers might lose interest, thinking the OP has been given an answer, etc.

That was not what I asked for. I wanted the declaration. You gave me the value.

It was however, unexpectedly useful information.

A common cause of porting issues similar to those you experienced is that the original programmer made inappropriate assumptions about the relative sizes of objects such as void* and int.

I thought about asking about those, but it seemed both a long shot and a hard question. Solaris has void* either 4 bytes or 8 bytes, but 8 is more common. Linux has void* also either 4 bytes or 8 bytes, with 4 more common. Suspecting a change in sizeof(void*) as a significant component of the bug is only likely if it changed from 4 to 8, which is unusual when changing from Solaris to Linux.

But in fact, by showing me the values, you did show me the sizes and sizeof(void*) was 4 in your Solaris system and 8 in your Linux system.

I also asked for the definition of build_tag. Since you left off the top of that function definition, I don't know what it is, but I don't think it is the definition of build_tag.

My just guessing that the change in size of void* is an important factor in the bug, is not enough. We need to find the code that contains the inappropriate assumptions about the size of void*

You can conclude that %p displays a 64bit address in that Linux system, so you can conclude the code was compiled as x86_64, not x86.
You can be moderately confident that %p displays a 32bit address in that Solaris system (a 64 bit address with the high 32 bits zero is possible but on Solaris in this context, unlikely).

I also find it frustrating that the OP is neither using nor apparently understanding basic C programming terminology. That make discussing the real problem difficult. I would have complained about that myself if you hadn't already complained about it more than enough.

But at this point I'm joining the viewpoint that you're complaining about the flaws in the OP's posts too much and you're apparently not trying to help.

Sorry but, it's not a rude attitude to tell you to (re)learn some C basics, it looks like you've a not too easy job to do, but you are not good enough with some C programming basic concepts. You'll gain plenty of time to follow Sergei's advice.
There's no shame to have to learn something, so you don't have to take it as an attack!
Seeing how you're responding doesn't give me the like to help you, and maybe I'm not the only one!
To end, Sergei was thanked 56 times... So his posts make sense for some people around there...