Re: [go-nuts] [net.mail] ReadMessage returns nil, io.EOF when email w/o body.

['Jim Idle' via golang-nuts]

If you are doing any serious email work, you might find that the enmime
module is useful.

https://github.com/jhillyerd/enmime

And perhaps this:

https://github.com/gatherstars-com/jwz

Jim

On Wed, Jul 19, 2023 at 9:07 AM Karan Gupta  wrote:

> That is correct. It is the same issue.
> Thanks for the help.
>
> -Karan
>
>
> On Wed, 19 Jul, 2023, 05:15 Ian Lance Taylor,  wrote:
>
>> On Tue, Jul 18, 2023 at 4:36 PM Karan Gupta 
>> wrote:
>> >
>> > RFC 5322 (https://www.rfc-editor.org/rfc/rfc5322#section-3.5) allows
>> for messages without bodies.
>> > ` A message consists of header fields, optionally followed by a message
>> body `
>> >
>> > However, the net/mail . ReadMessage returns an error when an email does
>> not contain a body.
>> > To demonstrate this I have written a small program (attached) that
>> shows the difference in values returned by mail.ReadMessage when the input
>> email message ends in
>> > 1. a 'field' where field is defined as in RFC5322. with focus on the
>> fact that 'field' ends in  a single CRLF
>> > 2. a body. In this specific case, I have chosen to use an empty body.
>> Email is constructed by appending 2 consecutive CRLFs to the message from
>> (1). The first CRLF is to separate the header from the body and the second
>> to terminate an empty body
>> >
>> > Is this a bug in the go standard library?
>>
>> I think you are describing https://go.dev/issue/33823, which, as it
>> happens, is fixed in the upcoming Go 1.21 release.
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAAtLhrc4tohZW9taHcyUHr09UN7X5u84XaJS6B_CSr2g-SurVw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGPPfg-QEXMcOVoYvJeZMZ_jN_1CdpVjKv1BeUcSFfxQEjS5tQ%40mail.gmail.com.

Re: [go-nuts] [net.mail] ReadMessage returns nil, io.EOF when email w/o body.

[Karan Gupta]

That is correct. It is the same issue.
Thanks for the help.

-Karan


On Wed, 19 Jul, 2023, 05:15 Ian Lance Taylor,  wrote:

> On Tue, Jul 18, 2023 at 4:36 PM Karan Gupta 
> wrote:
> >
> > RFC 5322 (https://www.rfc-editor.org/rfc/rfc5322#section-3.5) allows
> for messages without bodies.
> > ` A message consists of header fields, optionally followed by a message
> body `
> >
> > However, the net/mail . ReadMessage returns an error when an email does
> not contain a body.
> > To demonstrate this I have written a small program (attached) that shows
> the difference in values returned by mail.ReadMessage when the input email
> message ends in
> > 1. a 'field' where field is defined as in RFC5322. with focus on the
> fact that 'field' ends in  a single CRLF
> > 2. a body. In this specific case, I have chosen to use an empty body.
> Email is constructed by appending 2 consecutive CRLFs to the message from
> (1). The first CRLF is to separate the header from the body and the second
> to terminate an empty body
> >
> > Is this a bug in the go standard library?
>
> I think you are describing https://go.dev/issue/33823, which, as it
> happens, is fixed in the upcoming Go 1.21 release.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAAtLhrc4tohZW9taHcyUHr09UN7X5u84XaJS6B_CSr2g-SurVw%40mail.gmail.com.

Re: [go-nuts] [net.mail] ReadMessage returns nil, io.EOF when email w/o body.

[Ian Lance Taylor]

On Tue, Jul 18, 2023 at 4:36 PM Karan Gupta  wrote:
>
> RFC 5322 (https://www.rfc-editor.org/rfc/rfc5322#section-3.5) allows for 
> messages without bodies.
> ` A message consists of header fields, optionally followed by a message body `
>
> However, the net/mail . ReadMessage returns an error when an email does not 
> contain a body.
> To demonstrate this I have written a small program (attached) that shows the 
> difference in values returned by mail.ReadMessage when the input email 
> message ends in
> 1. a 'field' where field is defined as in RFC5322. with focus on the fact 
> that 'field' ends in  a single CRLF
> 2. a body. In this specific case, I have chosen to use an empty body. Email 
> is constructed by appending 2 consecutive CRLFs to the message from (1). The 
> first CRLF is to separate the header from the body and the second to 
> terminate an empty body
>
> Is this a bug in the go standard library?

I think you are describing https://go.dev/issue/33823, which, as it
happens, is fixed in the upcoming Go 1.21 release.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW_MRGDG%3Dq832pO69gjVA9MXY5sEF_dRz-LP3SYTrQ8Ag%40mail.gmail.com.

[go-nuts] [net.mail] ReadMessage returns nil, io.EOF when email w/o body.

[Karan Gupta]

Hello Everyone

RFC 5322 (https://www.rfc-editor.org/rfc/rfc5322#section-3.5) allows for 
messages without bodies.
` A message consists of header fields, optionally followed by a message body 
`

However, the net/mail . ReadMessage returns an error when an email does not 
contain a body.
To demonstrate this I have written a small program (attached) that shows 
the difference in values returned by mail.ReadMessage when the input email 
message ends in
1. a 'field' where field is defined as in RFC5322. with focus on the fact 
that 'field' ends in  a single CRLF
2. a body. In this specific case, I have chosen to use an empty body. Email 
is constructed by appending 2 consecutive CRLFs to the message from (1). 
The first CRLF is to separate the header from the body and the second to 
terminate an empty body

Is this a bug in the go standard library?

-Karan

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/23603880-d5c8-415c-b467-ba42e09cdb10n%40googlegroups.com.


email.go
Description: Binary data

[go-nuts] Re: testing whether two maps are the same object

[Jochen Voss]

Thanks Jason, I get your point about DeepEqual now :)

On Tuesday, 18 July 2023 at 16:52:51 UTC+1 Jason Phillips wrote:

> Also note: reflect.DeepEqual doesn't *just* compare the contents of the 
> map. It only compares contents if the maps aren't "the same map object". 
> From the documentation:
>
> > Map values are deeply equal when all of the following are true: they are 
> both nil or both non-nil, they have the same length, and either they are 
> the same map object or their corresponding keys (matched using Go equality) 
> map to deeply equal values.
>
> Comparing if they're "the same map object" is done in the way described 
> earlier, which seems exactly what you're looking for.
>
> On Tuesday, July 18, 2023 at 11:44:53 AM UTC-4 Jason Phillips wrote:
>
>> reflect.Value.UnsafePointer() is probably not safer than using unsafe 
>> directly, assuming you're using unsafe in a way that doesn't break the 
>> rules. Reflect is doing effectively the same unsafe.Pointer conversion 
>> under the hood [1]. It's certainly easier on the eyes, in my opinion, 
>> though.
>>
>> [1] - 
>> https://cs.opensource.google/go/go/+/refs/tags/go1.20.6:src/reflect/value.go;l=103
>>
>> On Tuesday, July 18, 2023 at 11:25:42 AM UTC-4 Stephen Illingworth wrote:
>>
>>>
>>> I like that. I think it's is quite a smart way of doing it,
>>>
>>> I don't think you need to check both maps when choosing a key. Once 
>>> you've found a candidate key in one map, you can test the other map and if 
>>> it *does* exist then the two maps aren't equal. You've then saved the 
>>> insertion and deletion step. I would also prefer to use rand.Int() rather 
>>> than a linear search. 
>>>
>>> https://go.dev/play/p/ftBGgQMuvvC
>>>
>>>
>>> On Tuesday, 18 July 2023 at 15:35:38 UTC+1 Jochen Voss wrote:
>>>
 Dear all,

 To implement the "eq" operator in a simple PostScript interpreter, I 
 need to determine whether two maps are the same object.

 This can be done by adding a new element to one map, and checking 
 whether the new entry also appears in the second map, but as you can 
 imagine, the resulting code is quite ugly.  See 
 https://go.dev/play/p/AfembYDt3en for an implementation of this idea.

 Is there a better way?

 Many thanks,
 Jochen



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c8b9aac5-6a53-472f-9c5d-497a23575a79n%40googlegroups.com.

[go-nuts] Re: testing whether two maps are the same object

[Jason Phillips]

Also note: reflect.DeepEqual doesn't *just* compare the contents of the 
map. It only compares contents if the maps aren't "the same map object". 
>From the documentation:

> Map values are deeply equal when all of the following are true: they are 
both nil or both non-nil, they have the same length, and either they are 
the same map object or their corresponding keys (matched using Go equality) 
map to deeply equal values.

Comparing if they're "the same map object" is done in the way described 
earlier, which seems exactly what you're looking for.

On Tuesday, July 18, 2023 at 11:44:53 AM UTC-4 Jason Phillips wrote:

> reflect.Value.UnsafePointer() is probably not safer than using unsafe 
> directly, assuming you're using unsafe in a way that doesn't break the 
> rules. Reflect is doing effectively the same unsafe.Pointer conversion 
> under the hood [1]. It's certainly easier on the eyes, in my opinion, 
> though.
>
> [1] - 
> https://cs.opensource.google/go/go/+/refs/tags/go1.20.6:src/reflect/value.go;l=103
>
> On Tuesday, July 18, 2023 at 11:25:42 AM UTC-4 Stephen Illingworth wrote:
>
>>
>> I like that. I think it's is quite a smart way of doing it,
>>
>> I don't think you need to check both maps when choosing a key. Once 
>> you've found a candidate key in one map, you can test the other map and if 
>> it *does* exist then the two maps aren't equal. You've then saved the 
>> insertion and deletion step. I would also prefer to use rand.Int() rather 
>> than a linear search. 
>>
>> https://go.dev/play/p/ftBGgQMuvvC
>>
>>
>> On Tuesday, 18 July 2023 at 15:35:38 UTC+1 Jochen Voss wrote:
>>
>>> Dear all,
>>>
>>> To implement the "eq" operator in a simple PostScript interpreter, I 
>>> need to determine whether two maps are the same object.
>>>
>>> This can be done by adding a new element to one map, and checking 
>>> whether the new entry also appears in the second map, but as you can 
>>> imagine, the resulting code is quite ugly.  See 
>>> https://go.dev/play/p/AfembYDt3en for an implementation of this idea.
>>>
>>> Is there a better way?
>>>
>>> Many thanks,
>>> Jochen
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/39c875f5-fa20-4c19-8028-e1eceb9b2818n%40googlegroups.com.

[go-nuts] Re: testing whether two maps are the same object

[Jason Phillips]

reflect.Value.UnsafePointer() is probably not safer than using unsafe 
directly, assuming you're using unsafe in a way that doesn't break the 
rules. Reflect is doing effectively the same unsafe.Pointer conversion 
under the hood [1]. It's certainly easier on the eyes, in my opinion, 
though.

[1] 
- 
https://cs.opensource.google/go/go/+/refs/tags/go1.20.6:src/reflect/value.go;l=103

On Tuesday, July 18, 2023 at 11:25:42 AM UTC-4 Stephen Illingworth wrote:

>
> I like that. I think it's is quite a smart way of doing it,
>
> I don't think you need to check both maps when choosing a key. Once you've 
> found a candidate key in one map, you can test the other map and if it 
> *does* exist then the two maps aren't equal. You've then saved the 
> insertion and deletion step. I would also prefer to use rand.Int() rather 
> than a linear search. 
>
> https://go.dev/play/p/ftBGgQMuvvC
>
>
> On Tuesday, 18 July 2023 at 15:35:38 UTC+1 Jochen Voss wrote:
>
>> Dear all,
>>
>> To implement the "eq" operator in a simple PostScript interpreter, I need 
>> to determine whether two maps are the same object.
>>
>> This can be done by adding a new element to one map, and checking whether 
>> the new entry also appears in the second map, but as you can imagine, the 
>> resulting code is quite ugly.  See https://go.dev/play/p/AfembYDt3en for 
>> an implementation of this idea.
>>
>> Is there a better way?
>>
>> Many thanks,
>> Jochen
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a2c2f09c-7cfe-476f-b29d-d0f131d600a5n%40googlegroups.com.

[go-nuts] Re: testing whether two maps are the same object

[Stephen Illingworth]

I like that. I think it's is quite a smart way of doing it,

I don't think you need to check both maps when choosing a key. Once you've 
found a candidate key in one map, you can test the other map and if it 
*does* exist then the two maps aren't equal. You've then saved the 
insertion and deletion step. I would also prefer to use rand.Int() rather 
than a linear search. 

https://go.dev/play/p/ftBGgQMuvvC


On Tuesday, 18 July 2023 at 15:35:38 UTC+1 Jochen Voss wrote:

> Dear all,
>
> To implement the "eq" operator in a simple PostScript interpreter, I need 
> to determine whether two maps are the same object.
>
> This can be done by adding a new element to one map, and checking whether 
> the new entry also appears in the second map, but as you can imagine, the 
> resulting code is quite ugly.  See https://go.dev/play/p/AfembYDt3en for 
> an implementation of this idea.
>
> Is there a better way?
>
> Many thanks,
> Jochen
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3217b6a4-5c22-43ba-b8a6-6c71745c6d65n%40googlegroups.com.

Re: [go-nuts] testing whether two maps are the same object

[Jochen Voss]

Dear Jason,

Thanks for the idea of using reflect.  Do you know whether 
`reflect.ValueOf(a).UnsafePointer()` is somehow "safer" than 
`*(*uintptr)(unsafe.Pointer())`?

reflect.DeepEqual will not work, since it just compares contents of the 
maps: https://go.dev/play/p/tE_qZI2cKEd

All the best,
Jochen
On Tuesday, 18 July 2023 at 15:52:24 UTC+1 Jason Phillips wrote:

> You can also use the reflect package rather than (directly) reaching for 
> unsafe. The reflect.DeepEqual function does something along the lines of: 
> https://go.dev/play/p/IVt0Z-mxugh
>
> On Tuesday, July 18, 2023 at 10:45:18 AM UTC-4 Jan Mercl wrote:
>
>> On Tue, Jul 18, 2023 at 4:35 PM Jochen Voss  wrote: 
>>
>> > Is there a better way? 
>>
>> I have never been here and please don't do this: 
>> https://go.dev/play/p/x4QYJubXMnQ 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/30202b52-554e-462e-aaa4-dfe7f4d23554n%40googlegroups.com.

Re: [go-nuts] testing whether two maps are the same object

[Jason Phillips]

You can also use the reflect package rather than (directly) reaching for 
unsafe. The reflect.DeepEqual function does something along the lines 
of: https://go.dev/play/p/IVt0Z-mxugh

On Tuesday, July 18, 2023 at 10:45:18 AM UTC-4 Jan Mercl wrote:

> On Tue, Jul 18, 2023 at 4:35 PM Jochen Voss  wrote:
>
> > Is there a better way?
>
> I have never been here and please don't do this:
> https://go.dev/play/p/x4QYJubXMnQ
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/073e5b30-5b4d-4125-9651-757c9bb96b6cn%40googlegroups.com.

Re: [go-nuts] testing whether two maps are the same object

[Jan Mercl]

On Tue, Jul 18, 2023 at 4:35 PM Jochen Voss  wrote:

> Is there a better way?

I have never been here and please don't do this:
https://go.dev/play/p/x4QYJubXMnQ

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Vy94Z%3D2LxbtTYqKzsNetBFcK66nHg28SP3zO9QK6xV9A%40mail.gmail.com.

[go-nuts] testing whether two maps are the same object

[Jochen Voss]

Dear all,

To implement the "eq" operator in a simple PostScript interpreter, I need 
to determine whether two maps are the same object.

This can be done by adding a new element to one map, and checking whether 
the new entry also appears in the second map, but as you can imagine, the 
resulting code is quite ugly.  See https://go.dev/play/p/AfembYDt3en for an 
implementation of this idea.

Is there a better way?

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9f5e5eb6-faee-4918-9a7f-e441ac15ecadn%40googlegroups.com.

Re: [go-nuts] map type conversion

['Jakob Borg' via golang-nuts]

On 17 Jul 2023, at 14:50, Leonard Mittmann  wrote:

Yes, but my thought was that it might be possible to do an unsafe conversion as 
the underlying types are the same. I just have no idea how.

https://go.dev/play/p/ViLnLvInv-1

The unsafe conversion appears to work, but it’s unsafe and not obvious to me 
that this is guaranteed to work. It’s allowed to convert one pointer to another 
if they have an “equivalent memory layout”, and I would guess that two map 
types with equivalent underlying types would share memory layout, but I don’t 
think the specs say anything about map memory layouts one way or the other.

//jb

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/AA75B829-B48F-4207-8D5F-9B75B2D17FAD%40kastelo.net.