Hi!
I'm using c language.
I need to copy a long type value into a char string using a memcpy
function:
memcpy(string, (long *) value, len)
this value will be then insert into a database.
On windows machine it works well, on Solaris not. The windows and
solaris path into c language is the same.
I'd like to say also that real value works correctly also if they are
used in the same manner:
memcpy(string, (real *) value, len)
Is there a particular manner to use long values on solaris?
Or to use memcpy with long types?
Thank you very much, I hope to be clear.
28  2512  si*********@goo glemail.com wrote:
Hi!
I'm using c language.
I need to copy a long type value into a char string using a memcpy
function:
memcpy(string, (long *) value, len)
this value will be then insert into a database.
I'm not sure what you hope to achieve by casting value to (long*),
you'll have to be more clear as to what your intentions actually are.
On windows machine it works well, on Solaris not. The windows and
solaris path into c language is the same.
I'd like to say also that real value works correctly also if they are
used in the same manner:
memcpy(string, (real *) value, len)
Is there a particular manner to use long values on solaris?
Or to use memcpy with long types?
memcpy doesn't care about types, it simply copies bytes.
--
Clark S. Cox III cl*******@gmail .com si*********@goo glemail.com wrote:
I'm using c language.
I need to copy a long type value into a char string using a memcpy
function:
why?
memcpy(string, (long *) value, len)
if value is a long why do you cast it to a (long*)?
I'd probably code it like this:-
memcpy (string, &value, sizeof value);
this value will be then insert into a database.
On windows machine it works well, on Solaris not.
what does "not work well" mean?
The windows and
solaris path into c language is the same.
I'd like to say also that real value works correctly also if they are
used in the same manner:
memcpy(string, (real *) value, len)
?? "real" is not a C type I recognise.
Is there a particular manner to use long values on solaris?
Or to use memcpy with long types?
Thank you very much, I hope to be clear.
well no...
Its possible the bytes are arranged in a different order between
Windows and Solaris. A so called "endian" problem. You may
have to rearrage the bytes in the string before the write.
You need to explain what your problem is.
--
Nick Keighley
GOD IS REAL.
Unless a type declaration to the contrary is made.
(old FORTRAN joke) si*********@goo glemail.com wrote:
Hi!
I'm using c language.
I need to copy a long type value into a char string using a memcpy
function:
memcpy(string, (long *) value, len)
this value will be then insert into a database.
This code is almost certainly wrong, but because you haven't
shown us any of the other declarations and uses it's hard
to say what, exactly, is wrong.
I say it's wrong because you have a cast `(long *) value`. Either
`value` is a pointer type (even though you imply that it's a long),
in which case you don't need the cast [1], or it isn't, in which
case you're handing a non-pointer to `memcpy`, BOOM.
I wonder if you meant `&value`? In which case, again, you don't
need the cast [1].
How many bytes are you copying? We don't know what `len` is.
One hopes that it's `sizeof(long)`. One also hopes that the
"string" location is long enough. One hopes that it has enough
space for the terminating 0. The code you show doesn't put the
terminating 0 in. Of course, maybe some unshown code does. Or
perhaps "string" isn't the right name for the variable.
How many bytes is the database expecting? What makes you think
that `len` is the right number, and what makes you think that a
`long` is exactly that wide? Because if a `long` is shorter
than that, you'll be copying rubbish; and if longer, you'll miss
out on some bytes, maybe the most relevant ones [2].
On windows machine it works well, on Solaris not.
What kind of ill working do you see?
The windows and solaris path into c language is the same.
"I don't know what that means" [3].
I suspect you're hitting an endianness / sizeof problem,
which because you didn't anticipate it may be a right
buxxer to fix.
[1] Assuming that you've remembered to #include <string.h>.
[2] EG if the `long` has the value `17`, the bytes holding the
`17` are the relevant ones.
[3] Bones.
--
Chris "electric hedgehog" Dollin
"People are part of the design. It's dangerous to forget that." /Star Cops/
"si*********@go oglemail.com" <si*********@go oglemail.comwro te:
I'm using c language.
No kiddin'. And here I thought this was comp.lang.snobo l.
I need to copy a long type value into a char string using a memcpy
function:
memcpy(string, (long *) value, len)
this value will be then insert into a database.
On windows machine it works well, on Solaris not. The windows and
solaris path into c language is the same.
Post real code, not unclear snippets. Cut your code to the smallest
compilable program which still exhibits your problem, then
copy-and-paste (do _not_ retype!) that. Otherwise, we are left guessing.
(E.g., I could guess that whatever stands in for "len" in your actual
code is correct for Windows, most likely by accident, but incorrect for
Solaris. But without real code, that remains a guess.)
Richard si*********@goo glemail.com wrote:
Hi!
I'm using c language.
I need to copy a long type value into a char string using a memcpy
function:
memcpy(string, (long *) value, len)
this value will be then insert into a database.
Please post your code. Otherwise, questions like these surface:
1. Is value a long type or a pointer to a long type?
2. Does string point to vlaid and enough memory?
3. What are you assigning to len? sizeof long, perhaps.
>
On windows machine it works well, on Solaris not. The windows and
solaris path into c language is the same.
I'd like to say also that real value works correctly also if they are
used in the same manner:
memcpy(string, (real *) value, len)
Is there a particular manner to use long values on solaris?
Or to use memcpy with long types?
I am sure somebody can help if you post a complete C program
that exhibits the problem.
>
Thank you very much, I hope to be clear.
si*********@goo glemail.com <si*********@go oglemail.comwro te:
I'm using c language.
I need to copy a long type value into a char string using a memcpy
function:
memcpy(string, (long *) value, len)
If 'value' is a long int variable then this looks rather strange.
The second argument to memcpy() must be _pointer_, but here you
just cast the value to a pointer, so whatever the result of the
cast is (not necessarily something useful), this will be taken to
be an address that gets dereferenced from within memcpy(). Even
if this by accident shouldn't segfault, the value itself will de-
finitely not be copyied to 'string', just the content of the memory
it's (accidentally). pointing to. But even if you change that to
memcpy(string, &value, len)
what ends up in string isn't going to be a textual representation
of what's stored in 'value' but some binary data. I don't know
if that's what you want (but since you don't tell what 'string'
is and how it's going to be used it's hard to guess).
And then the question is what 'len' is supposed to be. You
don't show what type and value it has, so nobody can tell
if you use something reasonable.
this value will be then insert into a database.
If this is some code to assemble a SQL statement then this
is definitely not correct - you would need a textual repre-
sentation of 'value', not a copy of its binary value. To
get a textual representation of a value into a string use
sprintf().
On windows machine it works well, on Solaris not. The windows and
solaris path into c language is the same.
What does this second sentence mean? I never heard about a "path
into c language".
I'd like to say also that real value works correctly also if they are
used in the same manner:
memcpy(string, (real *) value, len)
Sorry, there's no 'real' type in C. Is this typedef-ed somewhere?
And if 'real' has a different size than a long int is this re-
flected in the value of 'len'?
Is there a particular manner to use long values on solaris?
Or to use memcpy with long types?
There's nothing special about using long int values on Solaris
(or any other system) if you use a reasonable (i.e. standard-
compliant) C compiler.
Thank you very much, I hope to be clear.
Sorry, it's rather unclear. Post at least some more context -
just a single line of code doesn't help, especially if you
don't tell what variables are that you use or what the
result of the memcpy() is going to be used for - the bit
about "insert into a database" doesn't mean a thing.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\______________ ____________ http://toerring.de
Sorry, I tried to simplify but I was not clear!
I said real but it's a double type.
I need to put a long value type or a real value type into a string.
This value then will be inserted into an oracle database.
to put this value into a string I do:
memcpy(string, value, sizeof(long)); for long type
or
memcpy(string, value, sizeof(double)) ; for a double type
On windows these assignment works well and in Oracle database I see the
right values.
On Solaris only the value of double type works well, I mean that is
correctly updated into the database.
The value of long type is not correctly inserted into the database
cause it's inserted the zero value.
So I think that double and long types are managed in a different way by
solaris, and long is managed in a different way by windows and by
solaris. I also thought to "endian" but it should effect also double,
isn't it?
Thank you, I hope to have explained better!
Kind regards
Chris Dollin ha scritto: si*********@goo glemail.com wrote:
Hi!
I'm using c language.
I need to copy a long type value into a char string using a memcpy
function:
memcpy(string, (long *) value, len)
this value will be then insert into a database.
This code is almost certainly wrong, but because you haven't
shown us any of the other declarations and uses it's hard
to say what, exactly, is wrong.
I say it's wrong because you have a cast `(long *) value`. Either
`value` is a pointer type (even though you imply that it's a long),
in which case you don't need the cast [1], or it isn't, in which
case you're handing a non-pointer to `memcpy`, BOOM.
I wonder if you meant `&value`? In which case, again, you don't
need the cast [1].
How many bytes are you copying? We don't know what `len` is.
One hopes that it's `sizeof(long)`. One also hopes that the
"string" location is long enough. One hopes that it has enough
space for the terminating 0. The code you show doesn't put the
terminating 0 in. Of course, maybe some unshown code does. Or
perhaps "string" isn't the right name for the variable.
How many bytes is the database expecting? What makes you think
that `len` is the right number, and what makes you think that a
`long` is exactly that wide? Because if a `long` is shorter
than that, you'll be copying rubbish; and if longer, you'll miss
out on some bytes, maybe the most relevant ones [2].
On windows machine it works well, on Solaris not.
What kind of ill working do you see?
The windows and solaris path into c language is the same.
"I don't know what that means" [3].
I suspect you're hitting an endianness / sizeof problem,
which because you didn't anticipate it may be a right
buxxer to fix.
[1] Assuming that you've remembered to #include <string.h>.
[2] EG if the `long` has the value `17`, the bytes holding the
`17` are the relevant ones.
[3] Bones.
--
Chris "electric hedgehog" Dollin
"People are part of the design. It's dangerous to forget that." /Star Cops/
Sorry,
I add some information.
The value have to be copied into a string with memcpy cause the value
are binded into the sql queries and not explicitly defined (insert into
.... values(:value1, value2) is a sample query where value1 and value2
are bind variables). So I don't need the "character" value of the long
value but the "binary" value, so... memcpy!
And then, yes, the string size is correct!
Thanks! si*********@goo glemail.com ha scritto:
Sorry, I tried to simplify but I was not clear!
I said real but it's a double type.
I need to put a long value type or a real value type into a string.
This value then will be inserted into an oracle database.
to put this value into a string I do:
memcpy(string, value, sizeof(long)); for long type
or
memcpy(string, value, sizeof(double)) ; for a double type
On windows these assignment works well and in Oracle database I see the
right values.
On Solaris only the value of double type works well, I mean that is
correctly updated into the database.
The value of long type is not correctly inserted into the database
cause it's inserted the zero value.
So I think that double and long types are managed in a different way by
solaris, and long is managed in a different way by windows and by
solaris. I also thought to "endian" but it should effect also double,
isn't it?
Thank you, I hope to have explained better!
Kind regards
Chris Dollin ha scritto:
si*********@goo glemail.com wrote:
Hi!
I'm using c language.
I need to copy a long type value into a char string using a memcpy
function:
memcpy(string, (long *) value, len)
this value will be then insert into a database.
This code is almost certainly wrong, but because you haven't
shown us any of the other declarations and uses it's hard
to say what, exactly, is wrong.
I say it's wrong because you have a cast `(long *) value`. Either
`value` is a pointer type (even though you imply that it's a long),
in which case you don't need the cast [1], or it isn't, in which
case you're handing a non-pointer to `memcpy`, BOOM.
I wonder if you meant `&value`? In which case, again, you don't
need the cast [1].
How many bytes are you copying? We don't know what `len` is.
One hopes that it's `sizeof(long)`. One also hopes that the
"string" location is long enough. One hopes that it has enough
space for the terminating 0. The code you show doesn't put the
terminating 0 in. Of course, maybe some unshown code does. Or
perhaps "string" isn't the right name for the variable.
How many bytes is the database expecting? What makes you think
that `len` is the right number, and what makes you think that a
`long` is exactly that wide? Because if a `long` is shorter
than that, you'll be copying rubbish; and if longer, you'll miss
out on some bytes, maybe the most relevant ones [2].
On windows machine it works well, on Solaris not.
What kind of ill working do you see?
The windows and solaris path into c language is the same.
"I don't know what that means" [3].
I suspect you're hitting an endianness / sizeof problem,
which because you didn't anticipate it may be a right
buxxer to fix.
[1] Assuming that you've remembered to #include <string.h>.
[2] EG if the `long` has the value `17`, the bytes holding the
`17` are the relevant ones.
[3] Bones.
--
Chris "electric hedgehog" Dollin
"People are part of the design. It's dangerous to forget that." /Star Cops/
si*********@goo glemail.com wrote:
(Please don't top-post. Your reply should follow, or be
interspersed with, the message you're replying to. Trim
away irrelevant material, of course.)
Sorry, I tried to simplify but I was not clear!
Hence "show exact code". If you don't know what's wrong,
you don't know what to simplify, and you don't know what
to leave out. Preferably you want a small example that
is complete ie can be compiled and run.
I said real but it's a double type.
I need to put a long value type or a real value type into a string.
That doesn't sound very safe. In fact it sounds completely
/un/safe. Depending on what you mean, exactly.
This value then will be inserted into an oracle database.
to put this value into a string I do:
memcpy(string, value, sizeof(long)); for long type
or
memcpy(string, value, sizeof(double)) ; for a double type
So all that stuff about (long *) was irrelevant?
It /looks/ like what you're doing is putting the bytes that
comprise the value into `string` and then, by implementation-
specific magic, sending them to the database. I hope that the
magic can cope with any character whatsoever in a string value.
I hope that you only ever do this on a single implementation,
because /different implementations use different representations
for the same C type/. Oops.
On windows these assignment works well and in Oracle database I see the
right values.
What are those "right values"?
On Solaris only the value of double type works well, I mean that is
correctly updated into the database.
The value of long type is not correctly inserted into the database
cause it's inserted the zero value.
I suspect that your Solaris long has sizeof your Windows long.
So I think that double and long types are managed in a different way by
solaris, and long is managed in a different way by windows and by
solaris. I also thought to "endian" but it should effect also double,
isn't it?
That depends. (Probably yes.) But I think the sizeof is your
problem. As a wiser hedgehog than I said:
>I suspect you're hitting an endianness / sizeof problem,
which because you didn't anticipate it may be a right
buxxer to fix.
You have to decide exactly what you want to store for your
long (and double) values and what platforms you might want
to use. Myself I'd have written the usual decimal representaion
and told the database the values were integers and floats,
and let /it/ handle the conversion issues.
--
Chris "electric hedgehog" Dollin
The shortcuts are all full of people using them. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Laura P |
last post by:
Hi,
I wasn't sure whether this should be posted in the Java are or in a
Solaris thread, so I shall post it in both. Sorry for the
duplication.
I am new to Solaris and am having trouble running a long Java command
from a shell script.
Firstly, my Solaris (8) / Java setup. Mu machine already had Java 1.2
|
by: Eric Brunel |
last post by:
Hi all,
I was creating a Tkinter widget in the style of the reversed tabs below Excel
worksheets and I stepped in a serious problem: the code I made makes python
crash with a seg fault, bus error or X11 BadGC error on both Solaris (2.6 and
2.7) and Linux (Mandrake 8.0); it doesn't crash on Windows. I tried to simplify
the script, but I couldn't reproduce the crash with a simpler code. So the code
below is somewhat long; sorry for that.
...
|
by: Karen Lau |
last post by:
Hi All,
I am trying to port some C++ libaries from Solaris to Windows to
create a dll. The library requires the use of long double data type
which is not supported by Microsoft Visual C++. Could anyone suggest
any other compiler that could do the job?
any suggestion would be much appreciated.
Thanks
|
by: Nishant Deshpande |
last post by:
On Solaris 64-bit:
sizeof(long) = 8
sizeof(double) = 8 !!!
So i figure i can't store a long with the same precision in a double.
But, when i create a long and assign its largest value to it, then
assign this to a double, then subtract the double from the long, I get
0.
|
by: music4 |
last post by:
Greetings,
I need to use a long long data type integer in my program, but how to print
it with printf() or an alternative? My platform is Solaris 2.7 32bit
operating system, and I use Sun Forte 6 C compiler.
Thanks in advance!
Evan
| | |
by: bq |
last post by:
Hello,
Two questions related to floating point support:
What C compilers for the wintel (MS Windows + x86) platform are C99
compliant as far as <math.h> and <tgmath.h> are concerned?
What wintel compilers support a 16-byte "long double" (with 33 decimal
digits of accuracy) including proper printf() support. I found some
compilers that did support "long double", but theirs was an 8-byte or
10-byte or 12-byte type with accuracy the...
|
by: David Mathog |
last post by:
I recently ran into a problem where a data file downloaded
from another site contained more than 4Gb of data and so
the index file to items within that data went from unsigned
4 byte integers to unsigned 8 byte integers. Naturally this
broke my code which uses fseek(), and can only offset by
longs, which on the target OS is a 4 byte integer.
There are ways around this using OS calls, but
as far as I can tell the C99 standard offers no...
|
by: %NAME% |
last post by:
I am using jdbc type2 connection via "COM.ibm.db2.jdbc.app.DB2Driver",
on Solaris
I first get this error when it tries to load the native
implementation:
java.sql.SQLException: java.lang.UnsatisfiedLinkError:
Can't load Sparc 32-bit .so on a Sparc v9 64-bit platform
at COM.ibm.db2.jdbc.app.DB2Driver.<init>(DB2Driver.java:240)
|
by: mg |
last post by:
When make gets to the _ctypes section, I am getting the following in
my output:
building '_ctypes' extension
creating build/temp.solaris-2.10-i86pc-2.5/home/ecuser/Python-2.5.1/
Modules/_ctypes
creating build/temp.solaris-2.10-i86pc-2.5/home/ecuser/Python-2.5.1/
Modules/_ctypes/libffi
creating build/temp.solaris-2.10-i86pc-2.5/home/ecuser/Python-2.5.1/
Modules/_ctypes/libffi/src
|
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: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
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...
| |
