X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
X-Recipient:	dj AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
	s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
	mime-version; bh=K1EliDMNHYggq0uwMECODliDz6d2PXvwrE6UOp6A/mI=; b=IpU1ARjNEzim
	sh/uUFOd9j7VMExa1tX2GDuh960R+aPGJVpa76JXgWEOXB6aH9hPGtGaigpOa8o2jal0kDKEVtCaM
	YzdLoUCOMcHrcud0rsdUTCUxNOZ8SoGAMiU9GbkTkQWbfTgdseK7ZO8kX5RhKRpeAlQIOrwIvi9/+
	WbGxpkW95cFp1wOMEPOFE4/JHui23CJaPG368VDW93awqJuCKNB5i+sfJya+moNTjlBC6NQhwEEPU
	i4R3D8pEnRbe7A0qzfD1+7uRMH8zWfS+kHK+cxgtxI6BE8K38Ler05jMBW4TaLr8rX9EG1uqntdmc
	cKaxtsUTSgkE8nPEuwYajA==;
Date:	Sun, 14 Apr 2024 17:30:38 +0300
Message-Id:	<86il0km2y9.fsf@gnu.org>
From:	"Eli Zaretskii (eliz AT gnu DOT org) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
To:	Pali <pali AT pali DOT im>
Cc:	dj AT delorie DOT com, sezeroz AT gmail DOT com, djgpp AT delorie DOT com
In-Reply-To:	<20240414134915.k77cmfrcycetjsm5@pali> (message from Pali on Sun,
	14 Apr 2024 15:49:15 +0200)
Subject:	Re: Error handling in __djgpp_set_page_attributes()
References:	<20240413225744 DOT sxdwqpaipq5acj3n AT pali>
	<86h6g4o638 DOT fsf AT gnu DOT org>
	<20240414082932 DOT pm4hht4c5agcysou AT pali>
	<861q78nuk3 DOT fsf AT gnu DOT org>
	<20240414100331 DOT yv4eqcr2ruhfbslk AT pali>
	<86sezome63 DOT fsf AT gnu DOT org>
	<20240414104251 DOT bjvvmf2qzvhus3ug AT pali>
	<86r0f8makl DOT fsf AT gnu DOT org>
	<20240414121034 DOT h34pjed3s3udathh AT pali>
	<86jzl0m5x8 DOT fsf AT gnu DOT org> <20240414134915 DOT k77cmfrcycetjsm5 AT pali>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> Date: Sun, 14 Apr 2024 15:49:15 +0200
> From: Pali <pali AT pali DOT im>
> Cc: dj AT delorie DOT com, sezeroz AT gmail DOT com, djgpp AT delorie DOT com
> 
> > So I think it's important to say that the OUT_ADDR is the offset from
> > the DS segment base, and use 'sbrk' and 'malloc' as examples of
> > functions that return such addresses, in contrast to
> > __dpmi_allocate_linear_memory and similar APIs.  IOW, say that offsets
> > from DS are the requirement, and use 'sbrk' etc. as examples of
> > satisfying the requirement.  The fact that __djgpp_set_page_attributes
> > translates to linear addresses is also worth mentioning.
> > 
> > > Important is that it is from allocator (not from any other source).
> > 
> > AFAIU, this is not a requirement.  For example, if I know that offset
> > 0x1000 from DS belongs to the program's address space (as it usually
> > is), I can use that as OUT_ADDR.  Right?
> 
> If the memory offset 0x1000 from DS comes from the allocator (as it
> usually is, created during startup) then it would work. But if the
> offset, lets say 0x100000 from DS is behind the last byte allocated by
> sbrk then it would fail.
> 
> It would fail because translation is done by _djgpp_memory_handle
> function and it works by looking into memory handles which were
> allocated by 'sbrk'.

But isn't the DS segment memory allocated via calls to 'sbrk', and
aren't its memory handles kept in __djgpp_memory_handle?

For example, when we read the executable code of a DJGPP program into
DPMI memory at startup, don't we allocate that memory via 'sbrk' and
store the handle in __djgpp_memory_handle?

> If you take uncommited memory via __dpmi_allocate_linear_memory function
> then it would not be from the allocator but still can be expressed as an
> offset from the DS.

I didn't mean just _any_ offset, I meant memory that is known to be
committed.

> Note that when __djgpp_nearptr_enable function was called and succeeded
> then any offset in 4GB address space is valid for DS, so also the memory
> obtained from the __dpmi_allocate_linear_memory function is
> automatically in the DS segment.

I didn't mean "fat DS", there's no need to take what I say ad
absurdum.  All I meant to say was that the address can come in some
other way, not just via a direct call to 'sbrk' or 'malloc'.

> Anyway, similar documentation update was already done to the function
> __djgpp_map_physical_memory which basically uses same code pattern as
> __djgpp_set_page_attributes. And therefore has same requirements for
> our_addr/num_bytes parameters.

That could mean we should make the same changes there as well.  Unless
I'm wrong in what I say above.

- Raw text -