473,700 Members | 2,806 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Pointing to high and low bytes of something

My code contains this declaration:

: typedef union {
: word Word;
: struct {
: byte Low;
: byte High;
: } Bytes;
: } reg;

The colons are not part of the declaration.

Assume that 'word' is always a 16-bit unsigned integral type, and that
'byte' is always an 8-bit unsigned integral type ('unsigned short int'
and 'unsigned char' respectively on my implementation) .

My understanding, after browsing through previous threads on this and
other newsgroup, is that given a variable Var of type reg, accessing
Var.Word after having assigned values to Var.Bytes.Low and
Var.Bytes.High or, conversely, accessing Var.Bytes.Low and
Var.Bytes.High after having assigned a value to Var.Word, results in
implementation-defined behavior (or possibly undefined behavior).

If it is indeed implementation-defined behavior, my question is: can
the implementation only take the liberty to choose whether
Var.Bytes.Low or Var.Bytes.High will contain the LSB of Var.Word, and
whether Var.Bytes.High or Var.Bytes.Low will contains the MSB, or can
the implementation take other liberties?

Intuitively, I would say that there is more than this (specifically,
that the compiler can insert padding after the first member of the
Bytes struct), but some articles I've read seemed to imply otherwise.

Anyway, it all comes down to: assume that I am willing to sacrifice
portability by forcing the maintainer to exchange the positions of the
two members of Bytes depending on the implementation; do I then have a
guarantee that Var.Bytes.Low will always evaluate to the LSB of
Var.Word, and that Var.Bytes.High will always evaluate to the MSB of
Var.Word?

If not, then I would gladly accept suggestions on how to change my
code.
Keep in mind that I need to access:
1) Var.Word (or its equivalent after the change) by address
2) Var.Bytes.Low (or its equivalent) by address
3) Var.Bytes.High (or its equivalent) by address
to the effect that this code can be modified in a straight-forward way
to work as intended:

: #include <stdlib.h>
: #include <stdio.h>
:
: int main() {
: reg Var;
: reg *VarWordP;
: reg *VarLSBP;
: reg *VarMSBP;
: VarWordP=&(Var. Word);
: VarLSBP=&(Var.B ytes.Low);
: VarMSBP=&(Var.B ytes.High);
: *VarWordP=0x123 4;
: printf("%x %x %x\n", *VarWordP, *VarLSBP, *VarMSBP);
: return 0;
: }

Assume type reg has been defined as above. I should always get
1234 34 12
as the program's output, save any changes that could be needed in the
printf() format specifiers.
by LjL
lj****@tiscali. it
Nov 13 '05 #1
19 5871
dl*****@tiscali net.it (Lorenzo J. Lucchini) wrote:
: typedef union {
: word Word;
: struct {
: byte Low;
: byte High;
: } Bytes;
: } reg; Assume that 'word' is always a 16-bit unsigned integral type, and that
'byte' is always an 8-bit unsigned integral type ('unsigned short int'
and 'unsigned char' respectively on my implementation) . If it is indeed implementation-defined behavior, my question is: can
the implementation only take the liberty to choose whether
Var.Bytes.Low or Var.Bytes.High will contain the LSB of Var.Word, and
whether Var.Bytes.High or Var.Bytes.Low will contains the MSB, or can
the implementation take other liberties?

Intuitively, I would say that there is more than this (specifically,
that the compiler can insert padding after the first member of the
Bytes struct), but some articles I've read seemed to imply otherwise.


They can, but I've never seen one that does; probably the scarcity of
implementations that do so is part of the reason for the belief that
they can't.

Richard
Nov 13 '05 #2
lj****@tiscalin et.it (Lorenzo J. Lucchini) wrote:
# My code contains this declaration:
#
# : typedef union {
# : word Word;
# : struct {
# : byte Low;
# : byte High;
# : } Bytes;
# : } reg;

# Anyway, it all comes down to: assume that I am willing to sacrifice
# portability by forcing the maintainer to exchange the positions of the

If you're willing to sacrafice portability, then try this on each machine
you're interested in, and if it works there, you're done. You can also
have a dynamic test in main(), perhaps,
{
reg x; x.Word = 0x1234;
if (x.Bytes.Low==0 x34 && x.Bytes.High==0 x12)
puts("reg okay");
else if (x.Bytes.Low==0 x12 && x.Bytes.High==0 x34)
puts("reg byte-swabbed");
else
puts("reg completely confused");
}

--
Derk Gwen http://derkgwen.250free.com/html/index.html
Raining down sulphur is like an endurance trial, man. Genocide is the
most exhausting activity one can engage in. Next to soccer.
Nov 13 '05 #3
In <1f************ **************@ posting.google. com> lj****@tiscalin et.it (Lorenzo J. Lucchini) writes:
My code contains this declaration:

: typedef union {
: word Word;
: struct {
: byte Low;
: byte High;
: } Bytes;
: } reg;

The colons are not part of the declaration.

Assume that 'word' is always a 16-bit unsigned integral type, and that
'byte' is always an 8-bit unsigned integral type ('unsigned short int'
and 'unsigned char' respectively on my implementation) .

My understanding, after browsing through previous threads on this and
other newsgroup, is that given a variable Var of type reg, accessing
Var.Word after having assigned values to Var.Bytes.Low and
Var.Bytes.Hi gh or, conversely, accessing Var.Bytes.Low and
Var.Bytes.Hi gh after having assigned a value to Var.Word, results in
implementati on-defined behavior (or possibly undefined behavior).
Accessing Var.Bytes.High and Var.Bytes.Low (after initialising Var.Word)
will always provide implementation-defined results, with no possibility
of undefined behaviour. But not the other way round.
If it is indeed implementation-defined behavior, my question is: can
the implementation only take the liberty to choose whether
Var.Bytes.Lo w or Var.Bytes.High will contain the LSB of Var.Word, and
whether Var.Bytes.High or Var.Bytes.Low will contains the MSB, or can
the implementation take other liberties?

Intuitively, I would say that there is more than this (specifically,
that the compiler can insert padding after the first member of the
Bytes struct), but some articles I've read seemed to imply otherwise.
Your intuition is correct: in theory, the compiler *can* do that.
In practice, padding bytes are inserted only when they serve a *good*
purpose. Inserting padding byte(s) between Low and High would be
downright perverse, since, *in the framework of your assumptions*, no
padding bytes are needed at all: you're merely aliasing a two-byte object
by two independent bytes.
Anyway, it all comes down to: assume that I am willing to sacrifice
portability by forcing the maintainer to exchange the positions of the
two members of Bytes depending on the implementation; do I then have a
guarantee that Var.Bytes.Low will always evaluate to the LSB of
Var.Word, and that Var.Bytes.High will always evaluate to the MSB of
Var.Word?
In practice, yes, assuming that your initial assumptions still hold.
If not, then I would gladly accept suggestions on how to change my
code.
Keep in mind that I need to access:
1) Var.Word (or its equivalent after the change) by address
2) Var.Bytes.Low (or its equivalent) by address
3) Var.Bytes.High (or its equivalent) by address
to the effect that this code can be modified in a straight-forward way
to work as intended:

: #include <stdlib.h>
: #include <stdio.h>
:
: int main() {
: reg Var;
: reg *VarWordP;
: reg *VarLSBP;
: reg *VarMSBP;
: VarWordP=&(Var. Word);
: VarLSBP=&(Var.B ytes.Low);
: VarMSBP=&(Var.B ytes.High);
: *VarWordP=0x123 4;
: printf("%x %x %x\n", *VarWordP, *VarLSBP, *VarMSBP);
: return 0;
: }

Assume type reg has been defined as above. I should always get
1234 34 12
as the program's output, save any changes that could be needed in the
printf() format specifiers.


You don't need the union at all for this purpose:

word foo, *wp = &foo;
byte *ph, *pl;
pl = (byte *)wp; /* or the other way round, depending on the */
ph = pl + 1; /* implementation */
*wp = 0x1234;
printf("%x %x %x\n", (unsigned)*wp, (unsigned)*lp, (unsigned)*hp);

Now, even the most perverse compiler cannot affect the behaviour of your
code: you're pointing at the two bytes of foo directly, without using
any structs and unions. The only (unavoidable) assumption (apart from the
ones explicitly stated at the beginning of your post) is about which of
the two bytes of a word is the LSB and which the MSB.

Also note the casts in the printf call: %x expects an unsigned value and
there is no guarantee that any of the three values will get promoted to
this type (signed int is far more probable). So, you must provide the
right type explicitly (again, the code will work without the casts as well
in practice, but you have nothing to gain by not doing the right thing).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #4
Derk Gwen <de******@HotPO P.com> wrote in message news:<vr******* *****@corp.supe rnews.com>...
lj****@tiscalin et.it (Lorenzo J. Lucchini) wrote:
[using unions to extract MSB and LSB from something]


If you're willing to sacrafice portability, then try this on each machine
you're interested in, and if it works there, you're done. You can also
have a dynamic test in main(), perhaps,
{
reg x; x.Word = 0x1234;
if (x.Bytes.Low==0 x34 && x.Bytes.High==0 x12)
puts("reg okay");
else if (x.Bytes.Low==0 x12 && x.Bytes.High==0 x34)
puts("reg byte-swabbed");
else
puts("reg completely confused");
}


I am interested in every machine someone could decide to compile my
code on.
By "sacrificin g portability" I simply mean that this hypothetical
person should go through the hassle of checking whether his or her
machine is little-endian or big-endian, and uncomment the relevant
#define.
What I would *not* like to get on any machine is the "reg completely
confused".
See the reply I'm just about to write to Dan Pop's article for further
questions about if and when the "confused" part can occur.

by LjL
lj****@tiscali. it
Nov 13 '05 #5
"Dan Pop" <Da*****@cern.c h> wrote:
You don't need the union at all for this purpose:

word foo, *wp = &foo;
byte *ph, *pl;
pl = (byte *)wp; /* or the other way round, depending on the */
ph = pl + 1; /* implementation */
*wp = 0x1234;
printf("%x %x %x\n", (unsigned)*wp, (unsigned)*lp, (unsigned)*hp);
ITYM pl ph
Now, even the most perverse compiler cannot affect the behaviour of your
code: you're pointing at the two bytes of foo directly, without using
any structs and unions. The only (unavoidable) assumption (apart from the
ones explicitly stated at the beginning of your post) is about which of
the two bytes of a word is the LSB and which the MSB.


You are pointing at two bytes of foo directly, yes. There are no
guarantees that what you get out will be either 0x12 or 0x34 for
either of the byte results. The object representation of an
unsigned integer type (apart from unsigned char) is not specified
to the level where you must be able to identify definite MSB and
LSB where the value is given as (MSB << n) + LSB -- the bits could
be organised in a different order, and there could be padding bits.

--
Simon.
Nov 13 '05 #6
Da*****@cern.ch (Dan Pop) wrote in message news:<bp******* ***@sunnews.cer n.ch>...
In <1f************ **************@ posting.google. com> lj****@tiscalin et.it (Lorenzo J. Lucchini) writes:
My code contains this declaration:

[unions to extract MSB and LSB from something]

My understanding, after browsing through previous threads on this and
other newsgroup, is that given a variable Var of type reg, accessing
Var.Word after having assigned values to Var.Bytes.Low and
Var.Bytes.Hi gh or, conversely, accessing Var.Bytes.Low and
Var.Bytes.Hi gh after having assigned a value to Var.Word, results in
implementati on-defined behavior (or possibly undefined behavior).
Accessing Var.Bytes.High and Var.Bytes.Low (after initialising Var.Word)
will always provide implementation-defined results, with no possibility
of undefined behaviour. But not the other way round.


What do you mean with "not the other way round"? That accessing
Var.Word after initializing Var.Bytes.High and Var.Bytes.Low could
result in *undefined* behavior? If so, then I'm already invoking nasal
demons.
[snip]

Intuitively, I would say that there is more than this (specifically,
that the compiler can insert padding after the first member of the
Bytes struct), but some articles I've read seemed to imply otherwise.


Your intuition is correct: in theory, the compiler *can* do that.
In practice, padding bytes are inserted only when they serve a *good*
purpose. Inserting padding byte(s) between Low and High would be
downright perverse, since, *in the framework of your assumptions*, no
padding bytes are needed at all: you're merely aliasing a two-byte object
by two independent bytes.


Couldn't an architecture require that my 'byte's be aligned on word
boundaries?
Then two of my 'byte's could have take two machine words, while one of
my 'word' would take only one machine word (assuming the machine word
is 16 bit).
Am I missing something the standard requires here?

(Note that, while I'm calling my types 'byte' and 'word', they don't
have to correspond to a machine byte and a machine word; they only
need to be 8 bits and 16 bits wide respectively. For the record,
'byte' and 'word' try to mimic machine bytes and machine words of a
Z80)
[Am I guaranteed my approach will work?]


In practice, yes, assuming that your initial assumptions still hold.


My assumptions will hold as soon as someone has changed the #define's
the way I told them to.
I have no problem with people having to change even more #define's to
tell my program which byte is in Var.Bytes.High and which is in
Var.Bytes.Low.. . but I *would* have a problem if someone could have a
machine where the result won't be right no matter which #define is
uncommented.
[snip]


You don't need the union at all for this purpose:

word foo, *wp = &foo;
byte *ph, *pl;
pl = (byte *)wp; /* or the other way round, depending on the */
ph = pl + 1; /* implementation */
*wp = 0x1234;
printf("%x %x %x\n", (unsigned)*wp, (unsigned)*lp, (unsigned)*hp);

Now, even the most perverse compiler cannot affect the behaviour of your
code: you're pointing at the two bytes of foo directly, without using
any structs and unions. The only (unavoidable) assumption (apart from the
ones explicitly stated at the beginning of your post) is about which of
the two bytes of a word is the LSB and which the MSB.


This looks like an interesting solution - to be sure I'm on the safe
side, if nothing else.
But... assuming the scenario I outlined above (machine with
word-aligned bytes and such) isn't forbidden by the standard, couldn't
it cause problems (or invoke demons) with this formulation, too?
I can see a hint that it shouldn't in the ANSI rationale, but I can't
call it more than a hint (I'm clueless, I'll admit).
Also note the casts in the printf call: %x expects an unsigned value and
there is no guarantee that any of the three values will get promoted to
this type (signed int is far more probable). So, you must provide the
right type explicitly (again, the code will work without the casts as well
in practice, but you have nothing to gain by not doing the right thing).


Thank you for pointing this out; I should remember this more often
than I currently do, since while the code might work, it's nowhere
near nice to see stuff like "ffffff3" where an "f3" was expected.

by LjL
lj****@inwind.i t
Nov 13 '05 #7
In <3f************ ***********@new s.optusnet.com. au> "Simon Biber" <ne**@ralminNOS PAM.cc> writes:
"Dan Pop" <Da*****@cern.c h> wrote:
You don't need the union at all for this purpose:

word foo, *wp = &foo;
byte *ph, *pl;
pl = (byte *)wp; /* or the other way round, depending on the */
ph = pl + 1; /* implementation */
*wp = 0x1234;
printf("%x %x %x\n", (unsigned)*wp, (unsigned)*lp, (unsigned)*hp);


ITYM pl ph
Now, even the most perverse compiler cannot affect the behaviour of your
code: you're pointing at the two bytes of foo directly, without using
any structs and unions. The only (unavoidable) assumption (apart from the
ones explicitly stated at the beginning of your post) is about which of
the two bytes of a word is the LSB and which the MSB.


You are pointing at two bytes of foo directly, yes. There are no
guarantees that what you get out will be either 0x12 or 0x34 for
either of the byte results. The object representation of an
unsigned integer type (apart from unsigned char) is not specified
to the level where you must be able to identify definite MSB and
LSB where the value is given as (MSB << n) + LSB -- the bits could
be organised in a different order, and there could be padding bits.


The initial set of assumptions excludes the possibility of padding bits:
there is no place for them in a 16-bit unsigned integer type.

Your observation about LSB and MSB is theoretically correct, but C
implementations on 8-bit bytes machines are supposed to use the
underlying hardware bit order, which never assigns the bits randomly.
The only known variation is the byte order, but not the order of bits
inside a byte.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #8
"Simon Biber" <ne**@ralminNOS PAM.cc> wrote in message news:<3f******* *************** *@news.optusnet .com.au>...
"Dan Pop" <Da*****@cern.c h> wrote:
You don't need the union at all for this purpose:

word foo, *wp = &foo;
byte *ph, *pl;
pl = (byte *)wp; /* or the other way round, depending on the */
ph = pl + 1; /* implementation */
*wp = 0x1234;
printf("%x %x %x\n", (unsigned)*wp, (unsigned)*lp, (unsigned)*hp);


ITYM pl ph
Now, even the most perverse compiler cannot affect the behaviour of your
code: you're pointing at the two bytes of foo directly, without using
any structs and unions. The only (unavoidable) assumption (apart from the
ones explicitly stated at the beginning of your post) is about which of
the two bytes of a word is the LSB and which the MSB.


You are pointing at two bytes of foo directly, yes. There are no
guarantees that what you get out will be either 0x12 or 0x34 for
either of the byte results. The object representation of an
unsigned integer type (apart from unsigned char) is not specified
to the level where you must be able to identify definite MSB and
LSB where the value is given as (MSB << n) + LSB -- the bits could
be organised in a different order, and there could be padding bits.


Add to this the fact that my initial assumptions ('byte' is an 8-bit
unsigned type, 'word' a 16-bit unsigned type) may not be met by *any*
type on a specific implementation.

I was pondering the implications this fact yesterday night before
sleeping: it seemed to me that the only viable way to be really
portable (but my definition of being 'portable' accepts having
#define's to tweak for each implementation) was to use an 'at least
8-bit wide unsigned type' (unsigned char, namely) instead of 'byte'
and an 'at least 16-bit wide unsigned type' (unsigned short int)
instead of 'word'; a consequence of this is that I'd have to
explicitly do every arithmetic operation in modulo-256 or
modulo-65536, while this was achieved quietly with 'exactly 8-bit' and
'exactly 16-bit' types.

Do you think many implementation will optimize my %256's and %65536's
away when they're compiling for a machine with 8-bit chars and 16-bit
shorts?
The knowledge that many do would help me undertake the change much
more light-heartedly.

The problem would remain, though, of how to access the MSB and LSB of
the at-least-16-bits-wide values (which would be guaranteed by my
modulo operations never to go past 65535).
Of course I can use shifts and masks... but those don't give lvalues,
while dereferenced pointers certainly can.

It would seem that I'll have to rework the logic of my program... but
I do hope I am mistaken here.
by LjL
lj****@tiscali. it
Nov 13 '05 #9
In <1f************ **************@ posting.google. com> lj****@tiscalin et.it (Lorenzo J. Lucchini) writes:
Da*****@cern.c h (Dan Pop) wrote in message news:<bp******* ***@sunnews.cer n.ch>...
In <1f************ **************@ posting.google. com> lj****@tiscalin et.it (Lorenzo J. Lucchini) writes:
>My code contains this declaration:
>
> [unions to extract MSB and LSB from something]
>
>My understanding, after browsing through previous threads on this and
>other newsgroup, is that given a variable Var of type reg, accessing
>Var.Word after having assigned values to Var.Bytes.Low and
>Var.Bytes.Hi gh or, conversely, accessing Var.Bytes.Low and
>Var.Bytes.Hi gh after having assigned a value to Var.Word, results in
>implementati on-defined behavior (or possibly undefined behavior).
Accessing Var.Bytes.High and Var.Bytes.Low (after initialising Var.Word)
will always provide implementation-defined results, with no possibility
of undefined behaviour. But not the other way round.


What do you mean with "not the other way round"? That accessing
Var.Word after initializing Var.Bytes.High and Var.Bytes.Low could
result in *undefined* behavior? If so, then I'm already invoking nasal
demons.


Yup. It cannot happen in your particular case, because there is no place
for padding bits, but you cannot count on it in the general case.
>[snip]

>Intuitively, I would say that there is more than this (specifically,
>that the compiler can insert padding after the first member of the
>Bytes struct), but some articles I've read seemed to imply otherwise.


Your intuition is correct: in theory, the compiler *can* do that.
In practice, padding bytes are inserted only when they serve a *good*
purpose. Inserting padding byte(s) between Low and High would be
downright perverse, since, *in the framework of your assumptions*, no
padding bytes are needed at all: you're merely aliasing a two-byte object
by two independent bytes.


Couldn't an architecture require that my 'byte's be aligned on word
boundaries?


Nope. Not as long as your 'byte' is defined as a character type.
Then two of my 'byte's could have take two machine words, while one of
my 'word' would take only one machine word (assuming the machine word
is 16 bit).
Am I missing something the standard requires here?
Yup. Character types have no alignment requirements. And your 'byte'
must be defined as a character type if it has to be an 8-bit type.
Any other standard C89 type is at least 16 bits wide.
(Note that, while I'm calling my types 'byte' and 'word', they don't
have to correspond to a machine byte and a machine word; they only
need to be 8 bits and 16 bits wide respectively. For the record,
'byte' and 'word' try to mimic machine bytes and machine words of a
Z80)
It doesn't matter. In C89, an 8-bit type is either a character type or
nothing at all.
You don't need the union at all for this purpose:

word foo, *wp = &foo;
byte *ph, *pl;
pl = (byte *)wp; /* or the other way round, depending on the */
ph = pl + 1; /* implementation */
*wp = 0x1234;
printf("%x %x %x\n", (unsigned)*wp, (unsigned)*pl, (unsigned)*ph);

Now, even the most perverse compiler cannot affect the behaviour of your
code: you're pointing at the two bytes of foo directly, without using
any structs and unions. The only (unavoidable) assumption (apart from the
ones explicitly stated at the beginning of your post) is about which of
the two bytes of a word is the LSB and which the MSB.


This looks like an interesting solution - to be sure I'm on the safe
side, if nothing else.
But... assuming the scenario I outlined above (machine with
word-aligned bytes and such) isn't forbidden by the standard, couldn't


There is no such thing. Character types have no alignment restrictions.
it cause problems (or invoke demons) with this formulation, too?
I can see a hint that it shouldn't in the ANSI rationale, but I can't
call it more than a hint (I'm clueless, I'll admit).


No, aliasing an object by an array of unsigned char is guaranteed to work.
Also note the casts in the printf call: %x expects an unsigned value and
there is no guarantee that any of the three values will get promoted to
this type (signed int is far more probable). So, you must provide the
right type explicitly (again, the code will work without the casts as well
in practice, but you have nothing to gain by not doing the right thing).


Thank you for pointing this out; I should remember this more often
than I currently do, since while the code might work, it's nowhere
near nice to see stuff like "ffffff3" where an "f3" was expected.


This is not going to happen if the types you use are unsigned, even if
the type they are promoted to is signed.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
3426
by: Jeremy Sanders | last post by:
Hi - I'd like to write a program which basically does a few snmpgets. I haven't been able to find a python package which gives you a nice high-level and simple way of doing this (like PHP has). Everything appears to be extremely low level. All I need is SNMPv1. Does anyone know of a simple python package for doing this? I'd rather have something written in pure python, so that it is easily cross-platform.
62
3372
by: christopher diggins | last post by:
Since nobody responded to my earlier post , I thought I would try to explain what I am doing a bit differently. When multiply inheriting pure virtual (abstract) base classes, a class obviously bloats quickly for each new vtable needed. Execution slows down considerably as well. You can work around this by using interfaces referemnces which have a pointer to the object and a pointer to an external function lookup table. This technique...
4
4462
by: James Roberge | last post by:
I am having a little trouble getting my union/struct to work correctly. I am creating a struct that will contain information about the status of various Z80 cpu registers in an emulator i am trying to write. some of the registers such as "DE" can be accessed as 16 bit data or the high and low bytes can be accessed separately. SO, "DE" refers to the 16 bit data, where "D" and "E" refer to the high and low bytes respectively. Here is...
1
5008
by: Jim | last post by:
Hello, I'm trying to do urllib.urlencode() with unicode correctly, and I wonder if some kind person could set me straight? My understanding is that I am supposed to be able to urlencode anything up to the top half of latin-1 -- decimal 128-255. I can't just send urlencode a unicode character:
1
2786
by: bwmiller16 | last post by:
Folks - I'm seeing this warning on the log...I'm curious if it has a more sinister meaning than what's expressed here. It seems to me that if IBM wants me to know about this then there might be something else going on... Linux AS 3 on UDB ESE 8 FP9.
23
1920
by: Gautam | last post by:
this piece of code assigns an int pointer(evident) to a char, and when i try to access the ascii value of the char through the integer pointer(p) , what i get is a junk value or not i don't know ! 'cause it shows consistent values for diff. chars , for eg. c = 'a' ans=>-9119
6
7150
by: Friso Wiskerke | last post by:
Hi all, I'm creating a fixed length textfile with data which is sent out to a third-party which in turn reads the file and processes it. Some of the characters are not part of the lower ASCII table. This causes problems because an » (&HC4) in the textfile is converted into 2 bytes on the receiving end which then in turn shifts the remaining data on the line one byte to the right... and in a fixed length textfile that's a disaster Is...
11
9810
by: Usenet User | last post by:
..NET 1.1/2.0 I have a need to display high-resolution scrollable images in a .NET application (Windows Forms). One well known solution is to create a Panel with AutoScroll set to "true" and then add a PictureBox or another Panel to it, that is used to display the image. The above approach works, however, to my surprise, .NET GDI+-based graphics are not really hi-res friendly.
17
7958
by: Cesar | last post by:
Hello people. I'm having a Winform app that contains a webbrowser control that keeps navigating from one page to another permanentrly to make some tests. The problem I'm having is that after a while, the application is using more than 100 or 150 Mb in RAM, and if I let it continue, it can leave the system without memory. I've been watching in some pages that other people has the same problem with this control when keep navigating for a...
0
8718
marktang
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...
0
8642
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,...
0
9206
Oralloy
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...
0
9066
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
8916
tracyyun
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...
1
6558
isladogs
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...
0
4652
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
2383
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2022
bsmnconsultancy
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...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.