Re: [GHC] #2795: The Network.Socket library does not take into account that the bits in the network are sent as big enddian.

2008-11-27 Thread GHC 
#2795: The Network.Socket library does not take into account that the bits in 
the
network are sent as big enddian.
---+
Reporter:  guest   |
Owner: 
Type:  bug |   
Status:  closed 
Priority:  normal  |
Milestone: 
   Component:  libraries/network   |  
Version: 
Severity:  major   |   
Resolution:  invalid
Keywords:  socket port number big-enddian little-enddian conflict  |   
Difficulty:  Unknown
Testcase:  |
   Os:  Linux  
Architecture:  x86 |  
---+
Changes (by igloo):

  * status:  new = closed
  * difficulty:  = Unknown
  * resolution:  = invalid

Comment:

 Agreed, not a bug.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2795#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #2795: The Network.Socket library does not take into account that the bits in the network are sent as big enddian.

2008-11-20 Thread GHC 
#2795: The Network.Socket library does not take into account that the bits in 
the
network are sent as big enddian.
---+
Reporter:  guest   |   
Owner:   
Type:  bug |  
Status:  new  
Priority:  normal  |   
Component:  libraries/network
 Version:  |
Severity:  major
Keywords:  socket port number big-enddian little-enddian conflict  |
Testcase:   
Architecture:  x86 |
  Os:  Linux
---+
 We got the  program (1) below that is supposed to open a server in the
 port 51777. However, when we run the program, we observed that the port
 created was the number  16842. We believe that this difference comes from
 the fact that we run the program in a little enddian machine (Intel
 processor) and the socket library consider big enddian numbers instead. If
 we take 51777 and converted as indicated by function conv (see (2)), the
 socket open is indeed 51777.

 Kind regards,
 Alejandro Russo  Josef Svenningsson

 (1)

 import Network.Socket
 import System



 main = do s - socket AF_INET Stream 0
   arg - getArgs
   let shost = head arg
   port  = PortNum 51777
   host - inet_addr shost
   putStrLn Making the server...
   bindSocket s (SockAddrInet port host)
   b - sIsBound s
   putStrLn Socket bounded!
   listen s 5
   putStrLn Listening OK
   putStrLn Waiting for clients...
   (s', c) - accept s
   putStrLn Client found!
   str - recv s' 255
   putStr Message received:
   putStr str

 (2)

 conv :: Word16 - Word16
 conv w16 = shiftL (fromIntegral a) 8 .|. fromIntegral b
where a = fromIntegral w16 :: Word8
  b = fromIntegral (shiftR w16 8) :: Word8

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2795
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2795: The Network.Socket library does not take into account that the bits in the network are sent as big enddian.

2008-11-20 Thread GHC 
#2795: The Network.Socket library does not take into account that the bits in 
the
network are sent as big enddian.
---+
Reporter:  guest   |
Owner:   
Type:  bug |   
Status:  new  
Priority:  normal  |
Milestone:   
   Component:  libraries/network   |  
Version:   
Severity:  major   |   
Resolution:   
Keywords:  socket port number big-enddian little-enddian conflict  | 
Testcase:   
Architecture:  x86 |
   Os:  Linux
---+
Comment (by felixmar):

 Hi Alejandro and Josef,

 This is not a bug, but the documentation for Network.Socket is lacking.
 !PortNumber is defined as
 {{{
 newtype PortNumber = PortNum Word16
 }}}
 The Word16 argument of !PortNum represents the internal port number of
 !PortNumber and is in network byte order. Because !PortNumber is an
 instance of Num you can define a !PortNumber value like this:
 {{{
 let port = 51777 :: PortNumber
 }}}
 The value 51777 will then be automatically converted to it's internal
 representation depending on the little-endianness or big-endianness of the
 processor.

 Regards,
 Felix

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2795#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs